Re: [Boost-build] Future development

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-10-04 21:28:06

David Abrahams wrote:
> on Wed Oct 03 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
> 
>> As I've mentioned before I have yet to hear an argument that makes
>> meta-make systems, like Cmake, worth the effort.
> 
> I'm not convinced one way or the other.  It seems like you have lots
> of fears which may or may not be realized.

We all have fears ;-) But I'm not speaking from fear. I'm only trying to 
be logical. So I have the simple question... How can we get away from 
having to test N+1 make systems when using Cmake?

>> First what we get from the Cmake community is that we don't develop 
>> *part* of the build system ourselves. 
> 
> Sounds significant to me; potentially *very* significant, since the
> high-level facilities provided by CMake are much more powerful than
> the very basic facilities provided by Perforce Jam.

Well, I'm not talking about Perforce Jam, but Boost Jam. It has 
progressed in many ways by now. So which high-level facilities are you 
thinking of? How do they help in writing Boost.Build on top of Cmake? 
How do they help in testing? And to be clear... Volodya is talking about 
Boost.Build v2, not only bjam.

>> What we also get is that we have to test our extra changes to
>> it. And we have to test that bugs in the make system are ours or
>> theirs (just like all that time we spend in figuring out if a C++
>> problem is a Boost bug or a vendor bug). And we have to test all the
>> make systems that Cmake produces. And we have to test Boost in all
>> the make systems Cmake produces (for example testing MSVC with both
>> nmake files and VS project files). We also gain the pleasure of
>> fielding user bug reports and figuring out which make system might
>> be at fault.
> 
> Is the KDE project having problems with any of these things?

How many platforms and make systems does KDE support? AFAIK it's only 
gmake on Unix like systems. Is there a large multi-platform project 
using Cmake?

> It
> doesn't seem like a foregone conclusion that the use of a meta-make
> will lead us into trouble.  Another way to look at it is that the make
> systems targeted by Cmake are all very stable and reliable, and CMake
> only uses their most basic and straightforward constructs.

It seems like a foregone conclusion to me. But of course I will be the 
last to claim I know everything... or even just tiny bit ;-)

> I'm not saying I know which approach is better, but I'm finding it
> hard to convince myself that using CMake would definitely lead to
> problems.

Which was the point of having someone experiment with Cmake. So here's a 
few questions about that experimentation...

* How much of the Boost.Build v2 functionality does it implement?
* How much code did that take to implement?
* How descriptive are the project and target descriptions? And how does 
it compare to BBv2?

But I guess most important...

* Does Cmake support correct interleaving of build action output when 
doing parallel builds?
* Will they ever, given that such functionality is up to the "real" make 
system?

Maybe I could get this info from all those Cmake emails months ago that 
I avoided commenting on. If so, links would be appreciated.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo