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).
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk