Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-04 01:20:03

Hi Ali,

> > 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
duplicate that.

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.

- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at