Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-22 13:25:02

> On Apr 20, 2016, at 10:49 AM, Robert Ramey <ramey_at_[hidden]> wrote:
> 
> Inspired by the recent discussion regarding CMake, I've spend some more time looking at this.  As a result, I've done the following.
> 
> a) I experimented with using CMake in the more customary manner in my canonical project Safe Numerics - (see Boost Library Incubator). The current version does distribute CMakeLists.txt around the subdirectories of the library root.  My original objections to doing this were assuaged when I realized that boost build does the same thing.  That is I typically have Jamfiles in side of test, example and sometimes other directories.
> 
> b) One of the features that I much like about Boost Build is the possibility of arbitrary nesting of Jamfiles.  This permits one to build/test a portion of one's library (e.g. test, example) as well as the whole library.  For a large library this is indispensable. In spite of what many people think, this is not easily supported with CMake. However, I have found that with some extra effort, it is possible to support this to the extent we need it.  So in this project ONE CAN BUILD (actually create an IDE project or makefile that builds) ANY OF THE "SUBPROJECTS" (TEST, EXAMPLE) AS WELL AS THE LIBRARY “SUPERPROJECT"

You can create high-level targets to build a subset of a library. Its not automatic, but still possible.

> 
> c) CMake is indispensable to me:
> 
> * it creates IDE projects for "any?" platform.  I use IDE alot.
> * everyone else uses it - so it makes it easier to promote my work to others.
> * it's easier to make work - still a pain though
> * There is lots of information, around the net about how to use CMake, how easy it is etc.  Although they help when you're looking for an answer (which is all the time) - they really betray how complex, arbitrary and complex the system is.
> * It has an almost of idiot proof GUI version which I use a lot.  I really like this.
> * CMake is well maintained and supported by it's promoters.
> 
> d) Boost Build
> * either just works (great!) or doesn't.  If it doesn't it's almost impossible fix without getting help
> * I've never run across anyone outside of boost who uses it.  It makes it harder to promote my work.
> * It's natural to compose projects into "super projects"
> * it's almost impossible to integrate with and IDE.  At one time, I had things setup so I could debug executables created with boost build with the Visual Studio IDE and debugger.  But it was just too fragile and time consuming to keep everything in sync.
> * it has a lot of "automatic" behavior which can be really, really confusion. A small example: you've got multiple compilers on your system. When it discovers this, it just picks the "best" one and you don't know which one you got until the project builds (or not).  I'm sure this was implemented this way to make usage of boost build "simple" but it has the opposite effect.  Much better would be fail immediately with a message "multiple compilers found:... use toolset=<compiler name> to select desired one."
> 
> Some Conclusions - I'm trying to not make this a rant
> 
> a) The ideal, platform independent build system does not yet exist.  I guessing it never will.  I'm sure it won't happen in my life time - but then I'm 68 - maybe you'll get lucky.
> 
> b) Both systems are much more fragile, complicated and opaque than their promoters try to make you believe.  It's not that they're lying, they truely believe in their own stuff.  There is much re-invention of the wheel - The each created their own (half-assed) little language for goodness sake!!!

Yes, and boost could provide a cmake module to provide high-level utilities for some of these common tasks.

> 
> c) Neither has really resolved the issue of nested projects in a clear way.  Boost Build probably does or can do this.  CMake has a system of "packages" and a whole 'nuther layer about "finding" them.  Assuming it can be made to work - given the amount of time I've invested in CMake, I should know how to do this by now.

I think nested projects are bad, and its made worse because tooling doesn’t support it well. I think the packaging approach is better. Dependencies can be found in a build-independent way using pkg-config. Eventually, the super boost project with submodulues would go away and people would build and install boost libraries using either bpm or cget. There may still be a boost super project that depends on all boost libraries, so all boost libraries can be easily installed using bpm or cget, but it wouldn’t rely on git submodules to bring the libraries together as that brings in its own set of problems.

> 
> d) I think it's time for Boost to be a little more open about tolerating/encouraging alternative build systems.  I think our documentation approach is a model.  Yeah it's a hodgepodge.  But the various ways of doing pretty much work and generally don't stop working and we don't have to constantly spend effort bringing things up to the latest greatest system (which we couldn't agree upon anyway).  We have libraries which have been going strong 15 years - and people can still read the docs.
> 
> e) We should find some way to recognize those who have made the system work as well it has.  Doug Gregor (boost book), Eric Niebler, Joel Guzman (quickbook). Vladimir Prus, Rene Rivera, Steve Watanabe.  I know there others but these come to mind immediately.
> 
> Note that I have only addressed the issue of library development which is my main interest.  I'm really not seeing this issues related to users of libraries.  In particular, CMake has the whole "find" thing which I'm still not even seeing the need for.  If I want to use a library, I can build the library and move it to a common place with the headers, specify the include directory and I'm on my way.  

But if that library has dependencies then you need to find the dependencies as well. Its like when I want to use Boost.Filesystem, I need to link in Boost.System as well. If boost provided pkg-config files then I would just say I want Boost.Filesystem and Boost.System would be linked in automatically.

> I'm sure someone will step up to enlighten me on this.
> 
> Robert Ramey
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost