Re: [boost] Thoughts on Boost v2

Subject: Re: [boost] Thoughts on Boost v2
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-23 08:15:29

On 22 May 2014 at 19:26, Stefan Seefeld wrote:

> > Thing is, BlackBerry initially let each team use whatever tooling it 
> > liked for BB10. The result was a disaster, and a huge amount of later 
> > work to unify the disparate build systems under a single meta build 
> > framework.
> 
> Others have succeeded. Consider yocto/openembedded and its "meta build
> framework".

Actually I don't believe they have. I am not aware of any meta build 
framework which is portable and is superior to cmake in terms of 
maturity and userbase (what you suggested was Linux only. If a 
majority of the world ran Linux, life would be easier for build 
systems). If I was aware of a better meta build tool to cmake, I 
would recommend that instead of cmake, as I have no love for cmake. 
It is simply the present least worst solution to my knowledge.

> (At the risk of diverting into a tool-specific discussion: I very much
> dislike the cmake approach the same way I dislike the automake tool:
> both generate Makefiles from templates, but those Makefiles are
> impossible to manage directly, so in the end it doesn't actually matter
> that you relay to (GNU) make for the final build, as you take away all
> advantages that tool itself offers. You could just as well have added
> the 'build' step to cmake itself. But, I don't really want to argue
> about cmake or any other specific tool here. That's against the very
> premise of the points I'm trying to make. :-) )

It seems to me that venerable old make has the huge advantage of 
scaling well (i.e. linearly). You can feed 20k source files to make 
and it scales reasonably. Most of the "better" build tools simply 
can't cope with 20k+ source files.

Which then begs the question, what does scale better than make? To my 
knowledge I'm only aware of Tup and Fabricate that really do. Both 
make use of filing system hooks to achieve often O(1) scaling. In 
hindsight, I probably should have mentioned those in my C++ Now 
position paper where I proposed a type export database based build 
system for post C++ 17 which is fine grained enough to pretend all 
your code is header only, including code ripples propagating over a 
RPC inter-process channel, as the theory is the same.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/