On 5/20/16 3:51 AM, Paul Fultz II wrote:
You don’t know what pip is?
Absolutely no idea. I even tried googling it.
And a fairly elaborate procedure. I can't imagine the function of such a tool would be given that all one has to do with CMake is download, unzip and invoke CMake. It can't be easier than that process.
Thats a lot more steps than just `pip install cget`.
LOL - maybe if I knew what pip was and had it installed on my machine. The procedure I used was only a couple of easy steps and already familiar to me. I'm doubtful I'm alone in this.
This is the only reference I've found to cget via a google search. I have to conclude that it's a niche product and not really relevant here.
cget doesn’t do any magic. As it says in the readme, it just runs the equivalent of these commands on a package:
mkdir build cd build cmake .. cmake --build . cmake --build . --target install
If this is all it does, then I don't see the point of this. All this effort to replace 5 lines of text with one? Why not just make a macro? You'd have to make a better case that this is a saving of some sort.
This is what people already do to build and install something from cmake.
LOL - not me - I've never used the command line version of CMake. I'm sure I'm not alone in this either.
So there you have it. I just can see any real need to have CMakeLists.txt in the library root. I understand it's a convention, but no one seems to depend upon it.
So I would just suggest that you do what the we library authors have done.
The library authors of hana and compute include a top-level cmake. Y
ou are the only author that doesn’t, and your cmake is not useful for installing the library, either. The cmake in serialization is only useful for you as a developer. Maybe. Certainly that was my only interest in making it. That's why i surprised when I could discern no difference in the functionality between the one I made and the one included with hana when I tried it. I'm also not getting what it means to install a header only library. It looks like it's just moving an include directory. Is that it? I have been unable to discern any difference in the operation of the CMake process which derives from the location of entry file.
Just include CMakeLists in your subdirectories next to Jam files and make it work. If this is intolerable for your library, just include it in the root of your library and wait for someone to complain. I doubt anyone ever will.
I believe library authors such as Louis do not want to hide the cmake file. Having it at the top-level makes it clear and obvious that the library
supports cmake. The user doesn’t have to search through documentation to find the “special” instructions for building with cmake, instead they can build and install the library using the same steps that is used for every other library that supports cmake. Really, the presence of CMake support is absolutely obvious to anyone who knows anything about CMake. It's not hidden.
Also, a little friendly advice. You might want to refrain from suggestions that you're going to clone boost - especially over such a ridiculously trivial issue. It makes you look silly and hard to take seriously.
But if boost can’t make this trivial change to better support cmake, then it would be hopeless for future changes in boost for better cmake support.
My experiments convince me that this change is not only trivial, it's absolutely unnecessary and will not effect the future of CMake as it relates to Boost one way or the other. It's totally pointless. Look at the upside, now if CMake fails to take hold on the more than the two libraries which now support it (3 if you include mine), out of the 130 that are there, you can always say - it's all because the Boost Oliarchy wouldn't endorse putting CMakeLists.txt in the library root directory!!! Good Luck with this. Robert Ramey