Manoj Srivastava writes ("Re: Bug#387684: make incompatibly breaks my makefile
and provides no way to fix"):
> There is a way to fix it; just forget the $(shell ...)
> wrapper.
No, that results in the variable value being split into several
commands, each of which gets executed separately.
What I want is to be able to write a multi-line value, defined in a
make variable, to a file.
Eg, supposing I want to run the following python script
#!/usr/bin/python
import somemodule
somemodule.invoke("$(SOME_COMPLICATED_MAKE_VARIABLE)")
from a Makefile target. How do I do it ?
The obvious answer is
define script
#!/usr/bin/python
import somemodule
somemodule.invoke("$(SOME_COMPLICATED_MAKE_VARIABLE)")
endef
target:
python -c $(script)
but that doesn't work because it runs each line as a separate
command. Making it work in 3.81 wouldn't help me because my makefiles
have to be compatible with make 3.80.
In 3.80 this can be solved by the hideous hack in my original report,
which is based on the fact that $(shell $(multiline_variable)) would
pass each line of $(multiline_variable) to the shell as a separate
argument:
define script
set -e; d=script.py; rm -f $$d; for f in "$$@";do echo "$$f" >>$$d; done
--
#!/usr/bin/python
import somemodule
somemodule.invoke("$(SOME_COMPLICATED_MAKE_VARIABLE)")
endef
target:
: $(shell $(script))
python script.py
But in 3.81 this has been changed, incompatibly, with no good reason.
Perhaps the only answer is
p=printf >>script.py "%s"
define script
$p '#!/usr/bin/python'
$p 'import somemodule'
$p 'somemodule.invoke("$(SOME_COMPLICATED_MAKE_VARIABLE)")'
endef
target:
: >script.py
$(script)
python script.py
but this is not only ugly but also really very awkward; in particular,
the quoting requirements inside the script are crazy and it's not
clear that any possible script is expressible.
It seems to me that it is a basic requirement of a language like make
that it is capable of running any command. That is, it should be
possible, by writing in make, to specify exactly which byte strings
are used for the command and each argument, and that all byte strings
should be specifiable as command arguments, just as you can with the
shell. (I suppose you might reasonably exclude byte strings
containing nuls or control characters.)
The new behaviour does not have this property, because it is not
apparently possible to cause make to invoke any external program with
an argument containing newlines without preceding backslashes.
> In any case, this is not likely to be a change that is going
> to be reverted -- if you are not happy with this canning of the
> commands to be executed directly, I am not sure we have a recourse.
It seems likely that the change I'm complaining about here is an
unforeseen consequence of the line-ending-handling change. We could
revert that whole thing (or make it only happen if POSIXLY_CORRECT).
Or we could revert to make 3.80 (is anyone depending on 3.81
behaviours, I wonder?) and I could go and bitch at upstream.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
