Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-12-17 01:30:22

Hi Pedro,

> So, I've hacked stage.jam and:
> This allows one to say:
> stage stage-MXFParser
> : MXFParser
> : <location>bin <lib-location>lib
> ;
> And it will place everything in bin, except static and import libs which
> will go to lib.
> This is most probably not the best approach to do this. I would prefer, for
> instance to say something like:
> <type>STATIC_LIB:<location>lib
> <location>bin

Yea, I'd say that the first approach, with <lib-location> does not scale. If
new target types are added, you need new features.

> Comments?

I'm really not sure. The way I handle it in my project was to have two
different stage targets, for binaries and for libraries. Here's the relevant

stage wi-bin
: $(3)
: <variant>debug:<location>$(CL_DIR)/$(1)-debug/bin .... ;

stage wi-lib
: $(4)
: <variant>debug:<location>$(CL_DIR)/$(1)-debug/lib
<variant>release:<location>$(CL_DIR)/$(1)-optimized/lib .... ;

alias wi : wi-lib wi-bin ;

As you see, there the list of binaries and libraries is passed explicitly,
because 'stage' could not traverse dependencies back then. Nowdays, it
probably can be expressed like:

stage wi-bin : $(top-level-targets) :
<location>bin <traverse-dependencies>on <include-types>EXE ;

stage wi-lib : $(top-level-targets) :
<location>lib <traverse-dependencies>on <include-types>LIB ;

alias wi : wi-bin wi-lib ;

I think this approach is somewhat simpler that what you propose. Besides, I
was planning to make <location> universal feature -- which can be used to
specify target location for all targets, not only 'stage'. In that case,
<location> will be directly handled by virtual-target.jam.

The only thing I'm really sure is that your refactoring of 'construct' is a
good thing -- so I'm gonna apply it no matter what we decide about the rest
of the patch.

- Volodya


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