Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-12-18 02:40:01

For a few last days, I was pondering about a problem I faced with Boost.Build,
and still don't know the right solution. I'd appreciate fresh look on it.

Suppose I have

lib a : a.cpp ;

Simple, right? Now, via some fancy logic in generators.jam, when building 'a',
only targets of type 'LIB' are returned. For example, on windows, response
files are not returned.

However, I have a custom toolset which has to return not only LIB, but also
additional target of type STATIC_DATA -- since that target will be processed

One obvious solution is to extend the <include-type> feature to work in this

lib a : a.cpp : <include-type>STATIC_DATA ;

that's probably enough for me, but it is not nice, since I'd have to put this
extra requirement on all lib targets.

Another solution is to remove the fancy logic which eliminates some targets.
This will work for me, and simplify code. Also, this is also needed to fix
the --clean option. It was requested that --clean does not remove targets in
other project, or at least in other project roots. Now it removes everything
bjam sees and that's not nice. But to implement right semantic, all virtual
targets must be seen and processed by top-level code.

So, this looks like an excellent approach, except for 'stage'.

exe a : a.cpp ;
stage dist : a ;

If 'a' returns all targets, then 'stage' will start to copy response files and
what not. Is it a problem? I think it's not that nice, but OTOH it won't
break anything. For real uses, it's easy to add <include-type> features to
stage only EXES (after I commit recent Pedro's patch).


- Volodya


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