AMDG
Note: bind _MSG means that $(_MSG) is a target
On 03/20/2014 11:10 AM, Jose . wrote:
> I read the BBv2 documentation and samples. I don't want to create my own
> generator, just to see "Hola" "Adios" as the output of this program:
>
> rule myecho
> {
> _MSG on $(<) = $(MSG) ;
> }
> actions myecho bind _MSG
> {
> echo "MSG = $(_MSG)" ;
> }
>
and you want the name of the file, rather than
the internal name. It doesn't really make sense
in this example.
Yes. Boost.Build doesn't make two passes. It makes three.
> constant MSG : "hola" ;
> make Hola : : @myecho ;
>
> constant MSG : "adios" ;
> make Adios : : @myecho ;
>
> Why I only see "adios" "adios" ? I guess it's because the variable inside
> the action is not evaluated until the action executes. But the rule myecho
> should be executed in the first pass, hence _MSG should contain "Hola" for
> target Hola, and "Adios" for target Adios.
>
> Am I missing anything?
1) Parse Jamfiles
2) Generate actual targets
3) Run updating actions
(This should make sense if you keep in mind that a
target in the Jamfile can end up creating several
actual targets for debug and release builds, static
vs. shared libraries, different compilers, etc.)
the rules are run in step 2 after MSG has already been
set to "adios".
This is what features (e.g. cxxflags) are for.
> How can I pass a different message to a Make rule
> depending on the target? Can I avoid creating a generator?
>
import feature : feature ;
feature message : : free ;
rule myecho ( targets * : sources * : properties * )
{
_MSG on $(targets) =
[ feature.get-values <message> : $(properties) ] ;
}
make adios : : @myecho : <message>adios ;
In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build