Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'

On May 20, 2016, at 10:30 AM, Robert Ramey wrote:

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.

pip comes installed on most operating systems except windows.

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?

Well it does more than those lines above. It downloads the package and unpacks it. It also sets the prefix path so cmake will find the dependencies that have been installed and it will setup the install prefix. It also handles removing packages that have been installed(including packages that depend on it), and it will automatically download and install dependencies as well. That saves a lot more than 5 lines of text.

Why not just make a macro?

A macro? What are you talking about?

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?

Well it copies the header files. A library might also install cmake packaging or pkgconfig to handle dependencies.

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.

Hiding the cmake in another directory is not obvious. I don’t see a cmake file, I assume the library doesn’t build with cmake. You could do all this manually, but the point of a tool is you don’t have to. Let the computer do the work for you, instead of the computer making you work.

...

...

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!!!

Most newer libraries coming into boost are supporting cmake, and its growing. My libraries support cmake as well. So this list will get larger.