Semantics of rules with several command fields.
Nicolas Desprès
I'm wondering what is semantic when several commands are provided for
one rule. Typical example is:
# Test several commands in a rule
ar = ar
ranlib = ranlib
cc = gcc
rule cc
description = CC $out
command = $cc -o $out -c $in
rule ar
description = AR $out
command = $ar cr $out $in &&
command = $ranlib $out
build foo.o: cc foo.c
build libfoo.a: ar foo.o
build all: phony || libfoo.a
# End of the file
Apparently, the current behavior of Ninja is to concat all the command
and to pass them to the forked shell (that's why I had to add &&). Of
course I could have written the command of the rule 'ar' on a single
line but I am wondering how this should work on other platform like
windows.
I think a good semantic would be to invoke each command one after each
other (no parallelism here) and to stop as soon as one fails.
If we stick to the "one command per rule" semantic many people would
be tempted to scripts to bundle the set of commands they have to call
but then you loose somehow all the variable expansions done by Ninja.
What do you think?
-Nico
Evan Martin
> I'm wondering what is semantic when several commands are provided for
> one rule.
Without talking about commands in particular, the normal semantics for
multiple values for a variable should be to shadow.
I'd expect:
foo = 1
baz = $foo
foo = 2
To result in baz=1 and foo=2.
> Typical example is:
>
> # Test several commands in a rule
> ar = ar
> ranlib = ranlib
> cc = gcc
>
> rule cc
> description = CC $out
> command = $cc -o $out -c $in
>
> rule ar
> description = AR $out
> command = $ar cr $out $in &&
> command = $ranlib $out
>
> build foo.o: cc foo.c
> build libfoo.a: ar foo.o
>
> build all: phony || libfoo.a
> # End of the file
>
> Apparently, the current behavior of Ninja is to concat all the command
> and to pass them to the forked shell (that's why I had to add &&).
I am surprised this is the behavior! It might be a bug.
> Of
> course I could have written the command of the rule 'ar' on a single
> line but I am wondering how this should work on other platform like
> windows.
>
> I think a good semantic would be to invoke each command one after each
> other (no parallelism here) and to stop as soon as one fails.
>
> If we stick to the "one command per rule" semantic many people would
> be tempted to scripts to bundle the set of commands they have to call
> but then you loose somehow all the variable expansions done by Ninja.
I'm ok with scripts for bundling commands. The scripts could take the
variable expansions as arguments.
Otherwise, I'm worried that we would need to parse the "command" value
to find the delimiters between multiple commands, which then means we
need to understand the contents of the string that we currently pass
to the shell.
Nicolas Desprès
> 2011/4/21 Nicolas Desprès <nicolas...@gmail.com>:
[...]
>>
>> I think a good semantic would be to invoke each command one after each
>> other (no parallelism here) and to stop as soon as one fails.
>>
>> If we stick to the "one command per rule" semantic many people would
>> be tempted to scripts to bundle the set of commands they have to call
>> but then you loose somehow all the variable expansions done by Ninja.
>
> I'm ok with scripts for bundling commands. The scripts could take the
> variable expansions as arguments.
>
Ok if we follow that path, then it would be interesting to have
special variables like $VERBOSE, $DRY_RUN set according to the option
passed to ninja to teach the script what to do. Also maybe the scripts
would be able to convert the depfile if it has not the right format.
[...]
--
Nicolas Desprès