Re: [boost] [CMake] what to do now?

Subject: Re: [boost] [CMake] what to do now?
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-04-14 12:22:23

On 4/14/16 8:50 AM, Louis Dionne wrote:
> Rene Rivera <grafikrobot <at> gmail.com> writes:
>
>>
>> On Wed, Apr 13, 2016 at 6:00 PM, Robert Ramey <ramey <at> rrsd.com> wrote:
>>
>>> On 4/13/16 3:37 PM, P F wrote:
>>>
>>>>
>>>> The CMakeLists.txt file should be in the top-level directory.
>>>>
>>>
>>> Hmmmm - says who?  I realize that this is the common way to do it.  But it
>>> ends up sprinkling CMakeList.txt files all over the place.  Doing it the
>>> way I've done makes supporting CMake much less intrusive and leaves the
>>> "footprint" of CMake support on par with build (boost build) easily
>>> permitting the user to select which he prefers.
>>
>> <http://www.boost.org/development/requirements.html#Organization>
>
> I think this recommendation is out of line with current practice. From my
> experience, the top level CMakeLists.txt file is almost always expected to
> appear at the root of the project. Out of the 25 most trending C++ projects
> this month on GitHub,

That may be true.  But doing it in this way is very intrusive and 
conflicts with fundamental aspects of the boost way of doing things. But 
I always respect convention - except when I don't.

>
> - 8 use CMake as a primary build tool
> - out of those, 7 have a CMakeLists.txt file at the root of the project

Actually I'm guessing that these projects support CMake as the only 
build tool.  But that's just a guess
>
> Unfortunately, there does not seem to be agreement about what build system to
> use (many use plain Makefiles), but among the ones that use CMake, agreement
> is on the CMakeLists.txt file being at the top level. Other notable projects
> that use CMake and include the CMakeLists.txt file at the root are Facebook's
> HHVM and Kitware's CMake itself. An example [1] on CMake's website also
> suggests doing this.

I don't agree with the work "Unfortunately".  Actually I don't agree 
with the "Un".  One of the key features of boost is that it tries to 
impose only the minimum requirements required to fulfill it's mission. 
Over the last 15 years we've seen huge evolution in build systems, 
documentation systems, social communication, etc.  Our system has 
permitted this evolution to occur without upending all the components 
are making us spend huge amount of time in maintenance.  In the places 
were to do work hard to get conformity, documentation, build systems, we 
get huge pushback from library authors who want to do things their own 
way.  (e.g. DOxygen documentation).

>
> Finally, FWIW, I think all the CMake-powered projects I've seen so far also
> put the top level CMakeLists.txt file at the root (but that is just my
> experience).

Another very, very, very bad idea.  This conflicts in a fundamental way 
with the goal of modularization.  It couples all the libraries together 
through the build system.  This kind of coupling is the biggest single 
feature which makes it harder to support a growing set of Boost libraries.

>
> Personnally, I will need something more authoritative than the requirement
> page you link above to be convinced of putting the CMakeLists.txt file in
> another place than the root of the project.

LOL - Boost is pretty easy - you pretty much have the right do whatever 
isn't specifically prohibited - even if it's a bad idea.  What you don't 
have the right to do is to put something in the boost root or in some 
other library just to implement some preference in your own library.

Robert Ramey

>
> Regards,
> Louis Dionne
>
> [1]: https://cmake.org/examples/
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>