Boost logo

Boost :

From: Thomas Witt (witt_at_[hidden])
Date: 2001-11-21 09:09:21

On Wednesday 21 November 2001 14:19, you wrote:
> ----- Original Message -----
> From: "Thomas Witt" <witt_at_[hidden]>
> > Ok, it took me a bit to find out, but
> >
> > What actually happens is: they are not propagated to subprojects or
> dependent
> > projects.
> Hmm; I'm fairly certain that they /are/ propagated to subprojects, in the
> sense that the BUILD settings affect all targets which are direct
> dependencies of the target you specify on the command line (or "all" if
> none is specified).

My problem is that direct deps can't handle our project structure very well.

It looks like this


LibX are static libs that will be linked to both apps, so directory structure
cannot reflect dependencies. To improve convenience I placed redirecting
Jamfiles in the cpp dirs that look like this

subproject lib1/cpp ;

subinclude . ;

As a result jam can be invoked from every project directory. With my current 
emacs compile configuration this is a must.
Is there a better way to handle this ?
> I don't see how propagation to a dependent target could be relevant; the
> build proceeds from the target you specify to all of its dependencies, not
> the other way around.
I do not understand this.
> I know that free features are not propagated to top-level targets which are
> specified as dependencies with <lib>name. That's because free features are
> assumed to not affect link-compatibility, so you may already have a
> suitable build of the dependency lying around.
I don't think the argument is valid. I would argue exact the other way round. 
As they do not affect link-c. they can be propagated. If they are propagated 
the suitable build will still be found. The set of rebuilt files will be the 
same in both cases(Did I miss something?).
I think of free-features as a way to specify how the build should behave. 
Think of a msgstyle feature for metrowerks or something like <cflags>-v. In 
my oppinion build behaviour should be the same for all targets(as long as 
they don't require different) of one jam invocation. 
> Does that make sense? I hope so.
> You can affect the BUILD settings of all targets which don't have an
> explicit default build specification by setting the default-BUILD variable.
> Perhaps this mechanism isn't too well thought out, and something more
> explicit is needed...
To me this feels overly clever. Commandline variables should behave like 
environment variables. Otherwise new user will have a hard time finding 
As a sidenote I use the commandline variables to handle build behaviour and 
toolset in emacs (I need to change this on-the-fly).
> -Dave
> Info:  Unsubscribe:
> <mailto:boost-unsubscribe_at_[hidden]>
> Your use of Yahoo! Groups is subject to
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001

Boost list run by bdawes at, gregod at, cpdaniel at, john at