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

Subject: Re: [boost] [CMake] what to do now?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-14 12:52:49

On Thursday, April 14, 2016 at 11:22:47 AM UTC-5, Robert Ramey wrote:
>
> 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 
>

No that's not true. Having a CMakeLists.txt at the top-level doesn't 
prevent a
library from using another build tool, especially since there is no other
build tool that uses CMakeLists.txt file for its build script. Zlib supports
both cmake and autotools for building. Llvm/clang used to support both
autotools and cmake(and have since moved to just cmake only). Both of these
libraries have the CMakeLists.txt at the top-level.

 

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

When we say put CMakeLists.txt at the top-level, we mean at the top-level of
the individual library not at the boost-super-project level. Futhermore, I 
see
no evidence whatsoever that having a CMakeLists.txt at the top-level vs in
some sub directory couples the library to the build system and conflicts 
with
boost modularization.
 

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

No one is suggesting putting a file in the boost root.
 

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