From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-09-26 12:22:27
On 09/26/07 10:36, Rene Rivera wrote:
> Larry Evans wrote:
>> The description of "updating" rules and actions in:
> It will work as described, and assuming the above is the entire content
> of the Jamfile, if you do:
> bjam -f Jamfile
>> So, I guess, when rules and like-named actions are only connected,
>> automatically, the make rule; otherwise, they have to be explicitly
>> connected with the generators.register-standard rule. Is that
> Volodya will have to answer that. But I believe all your observations
> here are based on the misunderstanding the difference between Boost.Jam
> and Boost.Build. Boost.Build is an abstraction on top of Boost.Jam, and
> hence the interface it presents to users is different than the one
> describe by the direct use of Boost.Jam.
Yep. Looks like you're right:
bjam -f Jamfile x
rule my-update x : y
...found 1 target...
...updating 1 target...
actions my-update x : y
ECHO "rule my-update" $(<) ":" $(>) ;
echo "actions my-update" $(<) ":" $(>) ;
echo "Jamfile:" ;
cat Jamfile ;
my-update x : y ;
...updated 1 target...
Compilation finished at Wed Sep 26 11:09:42
Thanks *very much* for the clarification. I read about
the difference between Boost.Build and Boost.Jam, but
didn't really understand all that much. The keyword
you used was *interface*. Somehow, it's got to be
made clear to the user where that interface lies.
For example, if the actions in the:
my-update x : y ;
and the Jamfile was:
import verbatim.jam ;
verbatim a : b.cpp ;
would command line:
cause invocation of the my-update rule then the my-update actions?
I guess I'm still confused about where this Boost.Jam assocation of
rules and actions is useful. Could you give some examples?
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