Re: [Boost-build] build features and pathnames and effect on other libraries

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-05-25 14:57:44

   Hi Frank

> I'm using Boost through the Jamfiles directly (that is "use-project 
> boost : [ os.environ BOOST_ROOT ] ;"). When creating some libraries I 
> introduce features for its build variants:
> 
> feature usewide : no yes : propagated ;
> lib foo : foo.cpp
> 	: <usewide>yes:<define>FOO_USE_WIDE
> 	:
> 	: <include>.
> 	;
> 
> Now users of this lib and boost, like:
> 
> exe bar : foo /boost//system ;
> 
> they will force the feature "usewide" on boost as well. Boost will have 
> "usewide-no" in its build path, but boost will not be affected by the 
> <define> anyhow. Is there a way not to propagate the feature to boost? 
> With several libraries the features will make the path be too long and 
> additionally boost will be recompiled for each feature, needlessly.
> 
> I could imagine some "realm" for features, marking all targets where the 
> feature must affect the build path. And a way to propagate only 
> "upwards", meaning from the lib up to the exe, but not from the exe down 
> to boost.
> 
> Could that be useful to others?

   Yup... I believe that is one of the things missing in Boost Build. A 
way to localize features.

   Applying a feature to all projects depending on a target from a 
project with a feature seems logical. I am not sure though about that 
term 'propagated' as that is already used to feature values propagated 
to source targets. Although I do not believe this should apply to 
project targets, i.e. when referencing a sub-project using a use-project 
or build-project rule.

   With the following project structure:

     Project A
       Subproject B1
         Subproject C1
       Subproject B2
         Subproject C2

   Some use cases:

   1. Project A declares a feature F, local only to that project.
   2. Project B1 declares a feature F, local only to that project.
   3. Project C1 declares a feature F, local only to that project.
   4. Project B1 declares a feature F, that should affect all targets in 
projects B1 & C1.
   5. Project C1 declares a feature F, that should affect all targets in 
projects C2.

   (Not sure if all of them are useful.)

   Some question marks that pop up... Imagine the following situation:
   * Target A//tA having a source target B1//tB1 which does not depend 
on any further targets from project C1.
   * Project C1 declares a feature F, local only to that project C1.
   * Project B1 contains a target B1//tB2 which depends on a target C1//tC.
   Now, when you different targets should they be affected by feature F?
     * When you build target A ?
     * When you build target B1 ?
     * When you build target A//tA ?
     * When you build target B1//tB1?
     * When you build target B1//tB2?
     * When you build target B1//tC?
     * When you build all of those targets?

   Hopefully I'll find some time by the end of next week to give you 
some more feedback.

   Best regards,
     Jurko Gospodnetić

P.S.
   I have another idea related to properties, that I am hoping to get a 
chance to finalize soon - properties specified on targets when they are 
specified as sources. An extension of the current property set that can 
be stored for built targets (i.e. those that have an action attached to 
them) but which would allow this for existing ones as well. Will come in 
useful for example for defining installation packages as you can use 
this to say: place this source into this package under this path and you 
are free to place it under a different path in a different package and 
have other targets located in different paths in the same package.