Re: [jamming] Boost Build System prerelease

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-06-26 12:13:04

----- Original Message -----
From: "David Turner" <david.turner_at_[hidden]>

> First, I'd like to remark that you can use my "improved" version of Jam
today
> to run Boost on Windows 9x, since it is completely backwards compatible
with
> Jam 2.3.1 :-)

Yes, I've been referring Win9x users to your version, thanks.

> The changes have been submitted a long time ago to the Perforce
> team, and I'd love to see them rolled back into the main Jam source tree.

Me, too.

> On the other hand, It seems to me that Jam and Boost differ enormously in
> their designs, even if they share a common command language (and
interpreter);

Well, to be fair, the Boost design is based almost entirely on the Jam
design. The things I learned by studying the Jambase code were essential to
getting the boost stuff working.

> users of both systems need to think in vastly different ways to build
their
                                         ^^^^^^
Really? Maybe I'm just naive. Could you elaborate?

> projects with either one of them, since even the location of object files
> is different between them.

I don't think the file locations should be that much of a leap; almost
anyone who's built debug and release versions of a project or built with
multiple compilers has had to use a scheme something like this.

The subvariant path branching structure is a little unorthodox: I've had
requests from boosters for a flat build directory scheme (e.g. directories
like pc-linux-gnu-release), but I don't know how to handle platforms with
filename length restrictions (MacOS) or how to come up with a simple
translation between properties and directory name components. I think the
best solution would be to provide a user- (Jamrules-) overridable hook
function for translating paths.

> Jam is a marvelous piece of code, and many companies have already made a
> rather important investment on it. For example, did you know that the
> Apple MacOSX App.Builder IDE uses Jam as its internal build tool ?

No, that's nifty!

> This investment is also why I'd be really surprised to see the changes
> required for Boost integrated into the Jam source tree before long, since
> this would risk breaking too many existing installations/builds.

I think I was making something like this argument in
http://maillist.perforce.com/pipermail/jamming/2001-June/001229.html

All the same, I have never worked on a major project that could afford to
use a build system structured the way the Jambase rules are, with no simple
way to change compilers, build a different variant of the project, or ensure
link compatibility between separately-compiled objects. It is hard for me to
understand how a cross-platform project, e.g. Perforce, can use Jam
effectively without these facilities. Not that I consider any of this to be
a major failing of Jam, mind you: it provides nearly all of the neccessary
infrastructure to do the job, with most pieces incredibly well-thought-out.

> On one hand, I don't think that creating a fork is going to hurt any
> Jam users. On the other hand, it will certainly simplify the use of
> Boost, as well as its development.

Perhaps that makes the most sense.

> > >        - 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.
> >
> Agreed, though they could be used by other project-specific Jam/Boostfiles

Sure; but they can be used that way now. What am I missing?

BTW, one of the hardest things to get right was the split-path rule. It
generates reams of debugging output and might be better as an intrinsic
rule. Also, it's unable to remove the trailing slash from the top path
component, so:

[ split-path a:\b\c\d ] = a:\b c d

You might also notice that the boost build system hijacks unix-style
pathnames to do various things like specify multiple default build
subvariants and library dependencies:

    <lib>../foo/bar/my_lib # build and link in this library

    <runtime-link>static/dynamic # build both versions

In order to work properly cross-platform, this will require extending the
intrinsic path parsing code for platforms other than Windows and Unix. The
Perforce people have indicated that they would be happy to incorporate a
change to uniform unix-style path parsing so long as it works for /all/
supported platforms. Do you have any idea how VMS pathnames work <0.2wink>?

> > What is globbing?
> >
> Well, the name isn't correct. It's basically, the equivalent of the
> "wildcard" function in GNU Make, which is capable of returning a list
> of files or directories in a variable. It's generally something useful
> to scan sub-directories automatically, instead of having to patch a
> fixed list in a control file. Here are examples:
>
>    include  [ wildcard $(BOOST_INSTALL_PATH)/*-tools.jam ] ;
>    include  [ wildcard src/*/Jamfile ] ;

Oh, of course: you meant /globbing/ ;-). I'm not sure I have a use for it,
actually. Did you see a way it could help?

> > >        - 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.
> >
> Well, that's probably what the guys at the Software Carpentry project
> want to do. Unfortunately, it seems they're taking a long time to
> develop it (fortunately, the end result should be brilliant when
> completed !!) :-)

I've corresponded with Steven Knight about this. It's hard for me to tell
whether he actually has a solid idea of the neccessary foundation for such a
system. I think it might be fairly easy to slip calls to Python into the Jam
source and come up with an excellent system, but as I've said, that wouldn't
serve my users' needs.

> > 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...
> >
> Agreed, but I consider that the time spent improving software tools is
> nothing compared to the savings this allows in the future !!

I think my point was just that having a "partner in crime" makes it easier
to get over some of the little bumps in the road that less about development
than technology rasslin'.

Regards,
Dave