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