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.
> 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  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
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.
> Louis Dionne
> : https://cmake.org/examples/
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk