Re: [jamboost] Some thoughts on targets

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