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

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

Robert Ramey.