Re: [boost] build free-features

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

root/
   lib1/
      cpp/
   lib2/
      cpp/
   app1/
       cpp/
   app2/		
       cpp/

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: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de