From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-04 01:20:03
> > exe hello : hello.cpp @/stlport/stlport ;
> > exe hello : hello.cpp : <library>@/stlport/stlport ;
> > In both cases, everything must work if @/stlport/stlport produces
> > 1. A target for a searched-library
> > 2. A target which only conveys usage-requirements, but is not intended to
> > be consumed.
> > 3. No targets at all
> > Opinions?
> I'm thinking of this both in terms of the existing design and the new
> Target design I'm working on. In both cases, this sounds like an
> appropriate application of the "run-actions" functionality.
> There is a rule "feature.action" which registers rules to run associated
> with either a feature or a property. The rule is run in the context of
> processed properties and it is in the new design the very last stage of
> property processing (in the current design it is near the end of
> property processing). Each rule may create new properties to add to the
> property set.
As the person who invented "feature.action" rule, I certainly know about it
;-) And while it was invented precisely to handle stlport, now I don't feel
good about it. It's yet another way to customize V2, and it's better to keep
customization facilities to a minimum.
> So, we should always write
> exe hello : hello.cpp <stdlib>stlport ;
> and should register
> feature.action <stdlib>stlport : process-stlport ;
> and define
> rule process-stlport registered-property : context-properties
> // return appropriate combination of
> // <library>@/stlport/stlport
> // <include>...
> // <define>...
> // etc.
This has some negative issues. First, all we really want is to use certain
library. There is already existing mechanism how library can impose
properties on dependents: usage requirements. I don't think we should
Further, the code is much more complicated that you write above:
rule process-stlport ( registered-property : context-properties * )
local version = [ feature.get-values <stlport-version> :
$(context-properties) ] ;
# Use some data structure to obtain header/libraries for this version
# and add them.
# Add <library>@/stlport/stlport
Note that there'is already mechanism which can select right alternative of
@/stlport/stlport, based on version number. And proper usage requirements
will be selected as well.
> The only problem with this approach is that it won't work (I think).
> Because in both the existing and new designs, these rules get called
> after dependencies are generated (so the library won't be processed
> correctly). Of course, this rule could do that generation as well...
I think that's additional complication of feature.action. I think it's better
to support cases 1-3 above.
Use case 1. Suppose my program_options library is accepted to Boost,
and I'm pressed to implement both library version and all-inline version.
Someone might want to write
exe hello : hello.cpp @/boost/program_options%program_options ;
Ordinary, a library target will be created, and usage requirements (like
<include>/path/to/boost) will be applied. When user wants all-inline version
(using some feature, for example), he'd get no real target to consume, but
still, the usage requirements must be applied. Related case: I would like to
use some headers-only library from Boost. I should be able to write:
exe hello : hello.cpp : <use>@/boost ;
Here, @/boost is a project, and most likely you don't want to get all
libraries built. You, however, do want to get usage requirements.
I think in both cases some "not-file" virtual-target much be created, which
will carry usage requirement, but will not be consumed.
Use case 2.
exe hello : hello.cpp platform_sources ;
alias platform_sources : win.cpp : <os>NT ;
alias platform_sources ;
Now, on any OS except for NT, the "platform_sources" main target will generate
no files. I think this should be allowed.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk