Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-06 03:03:47

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

> David Abrahams wrote:
>> on Thu Oct 04 2007, Ray Lambert <codemonkey-AT-interthingy.net> wrote:
>> 
>>> Meta-make systems try to treat make like 
>>> a platform, but it isn't; it's just a tool and a very crude one at that.
>> 
>> That's all Cmake needs: something that can handle low-level targets,
>> dependencies, and build instructions.
>
> Makes me think I should refactor bjam into a build library, and tool. 
> Then convince Cmake to use the bjam build library ;-)
>
>>> Oh sure, it does still work, but so does a horse & buggy.  (And a
>>> H&B uses no gas and doesn't pollute; but I bet you're not willing to
>>> trade your car for one anytime soon...)
>> 
>> Exactly.  Unlike a horse and buggy, all makes I know are *extremely*
>> fast at the jobs for which they are used by Cmake.  The speed of
>> dependency analysis and issuance of build instructions (all make is
>> used for by Cmake) is one of the first things that gets optimized, and
>> make users scream if it is ever slow.
>
> You are including bjam in the "all makes I know" statement, right?

No, bjam isn't really a make anymore in that sense.  "Nobody" uses
bjam that way -- instead they use our large pile of libraries known as
Boost.Build.  Perforce Jam and its Jambase are low-level enough that I
would allow them as "a make," except that make is almost always the
main command-line build tool for a platform, and Jam has never reached
that level of adoption on any platform, so it hasn't had the same
pressure to excel at those low-level jobs.

>> I get the impression that you and Rene haven't taken the time to
>> understand how Cmake works.
>
> I've tried to at least follow the conversations about it, and had
> various personal conversations with Troy, and read some of the
> docs. But truth is, it's hard to put much more effort into
> understanding the intricacies of a tool I will never use. But then
> again it's really up to the proponents of Cmake to justify if and
> how it can perform the tasks BB+bjam does. I'll just try to mention
> as many as I can think of in case the proponents have forgotten some
> of them.

Would you at least be willing to try building Boost using the Cmake
tree Doug set up in SVN and look at the CMakeLists.txt files?  Your
feedback would be very valuable, especially because you know BB well
and because you are skeptical about using Cmake.

>> In most (maybe all) cases, it's not intended to generate a
>> standalone native make system.  In general, the makefiles it
>> generates can't be used by themselves.  All the interesting jobs
>> (like tracing header dependencies) are done by Cmake.
>
> There was a suggestion once, and some investigation as to
> implementation by the suggesting party, into implementing a bjam
> prebuild cache. This would be equivalent to the processing Cmake
> does to generate the sub-make descriptions.

Sort of... also a major redesign of the BB system AFAICT.

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