Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-05 02:59:45

on Thu Oct 04 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

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

The same way we get away from testing the assembler that your C++
compiler targets.  Just say no.

Just ignore the fact that Cmake uses other tools to get its job done,
just like you ignore the fact that (abstractly, anyway) GCC generates
assembly language and uses an assembler to convert that into machine
code.  Then you're just testing Cmake on each platform, if you really
feel that Kitware's extensive testing is inadequate.  Frankly, one of
the main attractions of Cmake for me is that I know someone else is
doing the testing.

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

I'm thinking of the ones that find your python installation, find your
compilers, and build installers, just to name a few.

> How do they help in writing Boost.Build on top of Cmake? 

You use them instead of writing complex toolset configuration.

> How do they help in testing? 

I don't understand the question.  How could high-level Cmake features
possibly help in testing?

> And to be clear... Volodya is talking about Boost.Build v2, not only
> bjam.

Yes, I realize that.  Cmake would replace bjam, large chunks of BBv2
implementation, and some significant parts of BBv2's interface.

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

I honestly don't know the answer to either of those questions.  I've
Bcc'd Bill Hoffman; hopefully he'll be able to tell us.

>> 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 ;-)

Yes, I can tell you're very certain; I just don't see how you can be.

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

I don't know, but that may not be a relevant question for Boost at
large.  I would ask how much of what we need for building and testing
Boost it implements.  According to Doug, it does everything we need.

> * How much code did that take to implement?

See for yourself.  Looks like it compares rather favorably with our
BBv2 codebase:
http://svn.boost.org/trac/boost/browser/sandbox-branches/boost-cmake/boost_1_34_0/tools/build/CMake

> * How descriptive are the project and target descriptions? And how does 
> it compare to BBv2?

Again, see for yourself.  The ones I can find are quite descriptive
enough.

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

I don't know how they do it, but parallel builds work, even when run
as part of a CTest system (which IIUC reads the build output).  Right
now the default testing system doesn't support parallel *runs*, but I
think that's easily fixed by making test output into targets as we
have done in Boost.Build.

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

I don't remember.  If so, you could dig them up as easily as I
could. ;-)

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com