Re: [boost] Boost Build improvements [RESEND]

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-16 12:07:18

----- Original Message -----
From: "Rene Rivera" <grafik_at_[hidden]>

> I thought the general Boost community might be interested in some changes
I
> made to the Boost (Jam) build rules...
>
> I'm using the Boost build system in my current project and I ran into a
couple
> of problems that made using it outside of Boost a little painful. My two
major
> pains where the inability to specify system include paths without them
being
> nuked somewhere. And the awkwardness of trying to use variants, but having
to
> define basically all the settings in a variant.
>
> The changes I've made are simple...
>
> 1. I added a <sysinclude> path feature that adds to the STDHDRS variable.
With
> this I also changed the include flag for gcc to use "-isystem" instead of
"-I"
> because that makes sure the includes fall in the correct place.

Great! I've been meaning to get to that.

> 2. I modified the definition of variants to be: "variant name [ on
> parent-name... ] ...". This reads, define a variant "name" based on the
> "parent-name(s)" variants. This makes it so that one can define a new
variant
> by changing only a few features that "override" the features in the
parent(s).

This is fantastic. It was a feature I had originally designed into the
system, but scrapped because of the following complication: what happens if
I define a build variant, say debug-python, derived from another, say debug,
and someone hands me a Jamfile which specifies a requirement:
<debug><define>FOOBAR. Does FOOBAR get defined when we build the
debug-python variant?

How does your patch approach the problem?

> These two changes make it so that I can, in my project, do something as
such:
> >>>
> project-root ;
>
> variant thot-common
>     :   <threading>multi
>         <rtti>off
>         <sysinclude>$(CVSROOT)
>     ;
>
> variant thot-debug on thot-common debug : ;
---------------------^^

That's really cute, but I have a reservation: "on" is a keyword. Jam is kind
of funny about letting you use keywords as regular symbols in other
contexts, but it makes me nervous. What about this instead:

    variant thot-debug : thot-common debug ;

Now, what does it mean? ;-)

I can guess that it means that thot-debug is everything in thot-common plus
every additional property given by the debug variant.

>
> variant thot-release on thot-common release : ;
>
> variant thot-profile on thot-common profile : ;
>
> >>>--a bunch of stuff cut here--
>
> subinclude utilities/diff_test ;
>
> subproject utilities/diff_test ;
>
> exe diff_test
>     :   diff_test.cpp
>         ../../base/Difference.cpp
>         ../../base/DataTransferImp.cpp
>         <lib>../../opencl
>     :   <sysinclude>$(OPENCL)
>     :   thot-debug thot-profile
>     ;
> >>>
> It's simple, easy to read, and makes managing global settings a breaze. It
> also happens to make for a much smaller "features.jam".

It sounds like a major improvement. Have you been following the jamboost
discussions (jamboost_at_[hidden])? They've been a little quiet lately,
but I plan to start them up again in the next couple of days, now that I
have a head of steam on the Python rewrite. I ask because the way you're
using this sounds like it's related to Vladimir's idea of being able to deal
with a project/subproject as a target which can have its own build
properties. These properties would be inherited by the targets defined in
the project unless they specify properties of their own.

> The files that I changes are attached, but they are based of the 1.25.x
> versions so it would take a bit of work from someone, hint-hint, to
integrate
> into the latest and greatest.

Thanks, I'll look, but a patch against the current CVS would be a big help.

-Dave