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

On May 20, 2016, at 12:21 AM, Robert Ramey wrote:

On 5/19/16 4:43 PM, Paul Fultz II wrote:

...

On Thursday, May 19, 2016 at 6:12:07 PM UTC-5, Raffi Enficiaud wrote:

...

...

Yet, the primary focus of a boost library is not its good cmake support.

It is for hana.

I looked through he CMakefiles for hana. It came to almost 800 lines. Obviously I just skimmed them. I don't see very many developers spending the extra effort to support this.

Then I decided to test it out on my system. I fired up my CMake program, pointed the source directory to hana and pointed to new build directory and let'er rip. I got three error messages - Couldn't find Boost, couldn't find Ruby and couldn't find doxygen. This is pretty normal. I don't have ruby nor doxygen on my system so I'll just ignore stuff. I always have to find the boost directory manually - probably because I don't use a command line switch. I fixed that and the complaint about using boost went away.

If found the CMake generated the xcode project in the expected place and opened it up. It takes forever (an hour!) for XCode to index the whole thing. This has nothing to do with hana or cmake of course. There are just a huge amount of tests and examples there. It does it all. With boost build, I can just point to one of subdirectories and build that. I don't know if this is possible with CMake. I'm doubtful as it seems that there's a lot of code in the library root CMakeLists which wouldn't be seen if I pointed to a sub directory.

One odd thing is that I have an ALL BUILD target but I don't have a RUN_TEST target. On my own CMake project I get both. ALL_BUILD just builds the executables and RUN_TEST executes them. I can't explain this.

After this discussion about the importance in the location of the CMake file. I was surprise to find that - aside from what was mentioned above, there is no distinguishable difference between the process and result between the hana build/test and the serialization one. The serialization one doesn't have a top level CMakeLists.txt. In fact it doesn't even have CMakeLists.txt in any directory other than cmake. So I can't see why this has any importance at all. I certainly doesn't in my case.

There has been mention of the necessity to have a top level CMakeLists.txt in order to respect convention so other tools work. I searched for other tools which might depend upon this and didn't find any. I understand that there is a convention of sprinkling these files around including the top level, but I could find anything that might depend on a particular structure....

except cget. I had never heard of this tool. All I found was a git hub project authored by you. It has only 1 contributor, and has been forked exactly once. Unfortunately, github doesn't record the number of times it's been cloned. I read the Readme page which describes it's function. It refers to something called pip which I have no idea about what it is.

You don’t know what pip is?

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`.

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 This is what people already do to build and install something from cmake.

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. You 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.

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.

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.