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/