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
> > 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 out. As a sidenote I use the commandline variables to handle build behaviour and toolset in emacs (I need to change this on-the-fly). Thomas > > -Dave > > > Info: http://www.boost.org Unsubscribe: > <mailto:boost-unsubscribe_at_[hidden]> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk