Re: [jamming] Boost Build System prerelease

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-06-26 08:01:43

----- Original Message -----
From: "David Turner" <david.turner_at_[hidden]>
> Hello David,
>
> >
> > As I announced last week, the proposed Boost Build System is now
available
> > for inspection.

> I just finished studying the Boost control files, and I'd like first
> to congratulate you for your work. What you've done is properly amazing !!

Thanks very much!

> I'd very much appreciate to be able to collaborate with you on the
> Boost build system.

This is great news.

> The Jamfiles you submitted brought several questions
> to mind:
>
>   - your modifications are rather important, since you've replaced most
>     of the original Jam build rules with different ones. Do you expect
>     this work to be incorporated back into Jam itself, or do you
>     intend to create a fork, in order to create an independent
>     build tool ?

Well, I planned to gauge reactions and make a determination about how to
approach things. I would love to compile those rules into Jam directly, but
I haven't got any reason to expect that Mr. Seiwald would incorporate my
work back into Jam, so I figured it was safest to assume I was going to be
stuck with -fallyourbase.jam for the forseeable future. The boost community
has rejected the idea of a completely independent fork (and I agree), so I
am trying to stay compatible with a stock Jam executable (though some of our
users certainly need your Win95/98 work). I think something that was likely
to be merged back into the Jam release (i.e. in the right part of the public
depot, and somewhat blessed by the Jam world) would be acceptable, though.

You may have more insight into the best approach here than I do, however,
since you've been part of the Jam community longer and have made valuable
source code modifications. Suggestions?

>   - if you intend to fork the tools, would you be interested in
>     extensions of the Jam C source files in order to support:
>
>        - built-in implementations of "sort", "unique", "intersection",
etc..

I think these are low-priority. Informal tests show that Jam spends much
more time checking file dates than it does in any of these processing rules.
The worst thing they do is to obscure debugging (-d+5) output. My tests
could be wrong, of course.

>        - additionnal language logic (e.g. variable rule call, like in
>           [ $(RULE)  $(PARAM1) : $(PARAM2) ], substitution, globbing,
etc.. )

Yes, the first one would be a huge help. There's one place in particular
that needs it. I have spoken to Mr. Seiwald about that and he seemed open to
the idea. What is globbing?

>        - other kinds of enhancements that could simplify the Boost
>          control files tremendously.

Simplicity is good. Ultimately I would love to have a Python interpreter
under the covers, but the boost community is not ready to accept Python as a
requirement for builds.

>    - would you be interested in creating new features ? The one I'm
>      interested in would be "<ansi>on|off" to toggle ANSI compliant
>      compilation of C source files.

Absolutely. The supported feature set is just a proof-of-concept.

> If you're interested, I'm ready to create a source archive that would
> compile the Boost build system into a single executable file for easier
> distribution. Simply let me know if you're interested..

I am very interested. A little guidance with the Perforce public depot would
also go a long way. There are so many things to do, and so little time to
learn new things...

> I'll try to contribute toolset contributions in the next days. I should
> be able to provide control files for Intel C, Watcom, LCC and a few other
> things..

Wonderful. I'm looking forward to collaborating with you.

-Dave