Re: [Boost-build] Future development

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-10-06 03:25:26

David Abrahams wrote:
> 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.

Well you may ignore that, but I don't. It's foolish to think we can 
understand a system without understanding it's parts, and taking those 
parts into consideration.

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

That is what I see as a fallacy. Kitware tests Cmake... They can't test 
all uses of Cmake (and as I mentioned elsewhere we are likely to stretch 
it past it's limits). Regardless, I fail to see how we can assume we 
only test Cmake on each platform when we will have to invoke both Cmake 
and /make/ on each platform for testing. We will, at some point, run 
into problems when running /make/ which we will have to diagnose and 
decide if it was a problem in BB layer, or Cmake, or /make/. Except that 
with Cmake that last one is different on each platform and hence we need 
to understand those N /make/ systems.

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

You mean python installation*s*, right? I've had as many as 5 in my 
machine at one point.

>> How do they help in writing Boost.Build on top of Cmake? 
> 
> You use them instead of writing complex toolset configuration.

Are the Cmake equivalents not complex?

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

Well you mentioned Python configuration. And on the testing list the 
subject of testing halting because the Python build Jamfile was 
non-functional when Python was not configured came up. So, for example, 
are you saying that Cmake would find the correct Python install in a 
testers machine without intervention from the tester? Are there other 
Cmake high level features that similarly help 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.

Since much of the testing of Boost is built around the functionality of 
BB and bjam... You have to consider that you would need to replace *all* 
of bjam, BB, process_jam_log, regression.py, and the whole of xsl_reports.

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

Design structure complexity. I look at Cmake, and I see adding a miriad 
of additional independent components to the testing pipeline. This 
immediately brings up flares in my head, as we are in a time when we are 
trying to reduce the number of components in the testing pipeline. My 
next reaction is to try and figure out why one would need those extra 
components, to determine if they are beneficial. But you've mentioned 
that Cmake uses those sub-components as essentially dumb build drivers. 
Which brings up the next set of flares in my head, as to why bother with 
components developed externally when it's just as easy to build those 
dumb features in. At which point I'm questioning how I can rely on 
something with such a flawed, IMO, design foundation.

But that is all stuff I already knew categorically about meta-make 
systems. I.e. that IMO they are structurally an inferior design.

>> * 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.

If Doug is relying on Dart as the reporting system end to make that 
judgment. And if you've discounted Dart as viable for Boost test 
reporting needs. How can it implement everything Boost needs?

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