Re: [jamboost] Staging libs and dlls to different locations

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 
code:

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