Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-05-20 11:30:17
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
Good Luck with this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk