Subject: Re: [Boost-build] Building a generator binary then using it?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-10-14 21:28:01
Alexander Sack wrote:
> Alright, my main issue is this is a lot of heavy lifting compared to
> just doing an install rule and then referencing it from some constant
> PATH which certainly works. Is there a reason why the build
> destination is not added to the PATH by default when bjam executes the
> command in a shell?
I don't think that's enough, as we may (for instance) always want
to use the release version of a generated tool.
Here's what is required currently:
a) create a feature
b) specify the variable that the feature should be bound to
c) create the action
d) specify the executable to use (somehow this needs to
make it into the requirements for every target using it.)
The minimum necessary is
a) specify the variable to stick the exe name in.
b) write an action
c) specify the executable
exe tblgen : tblgen.cpp ;
set-command tblgen : COMMAND : tblgen ;
actions tblgen bind COMMAND
$(COMMAND) $(>) >$(<)
make a.inc : a.td : @tblgen ;
Considerations on how to make the above work
It would be nice if this could somehow be integrated
toolset.flags tblgen COMMAND : tblgen ;
However, we would need to be careful to avoid breaking changes/surprises.
It seems that it would be safest to require such flags to
be explicitly specified as target references.
toolset.flags tblgen COMMAND : <target>tblgen ;
or some such...
If this is dealt with by adjusting toolset.handle-flag-value, then
it will be too late to propagate usage-requirements back. But,
I don't know that usage-requirements ought to be used in this case.
Also, this will work the same way for generators as for the make rule.
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