From: Ken Raeburn <address@hidden>
Date: Sun, 23 Aug 2009 14:43:04 -0400
Cc: Jason Rumney <address@hidden>, address@hidden
On Aug 23, 2009, at 14:02, Eli Zaretskii wrote:
I think it will be hard to DTRT without shell-specific targets: a
Unixy shell needs to see the backslash escaped, the Windows shell
needs to see it alone. $(ARGQUOTE) will not help here, since with
stock Windows shell, $(ARGQUOTE)\$(ARGQUOTE) evaluates to "\", and
the
backslash will escape the quote, which is not what we want.
Ugh. Well, there already seems to be some shell-specific coding in
nmake.defs and gmake.defs, so perhaps I can define $(BACKSLASH) to
expand to whatever is needed for a backslash inside $(ARGQUOTE),
namely two backslashes for sh and one for Windows? Though, in order
to get the backslash by itself, I'd need to avoid "\" acting as a
line
continuation character for make. Does that mean I need to double
them, or add just one more, or...?
No, no, no. The way to do it is like we do in lisp/makefile.w32-in,
for example:
compile-calc: compile-calc-$(SHELLTYPE)
compile-calc-CMD:
for %%f in ($(lisp)/calc/*.el) do $(emacs) $
(BYTE_COMPILE_EXTRA_FLAGS) -f batch-byte-compile %%f
compile-calc-SH:
for el in $(lisp)/calc/*.el; do \
echo Compiling $$el; \
$(emacs) $(BYTE_COMPILE_EXTRA_FLAGS) -f batch-byte-compile $
$el || exit 1; \
done
IOW, have the main rule call a different shell-specific rule according
to $(SHELLTYPE). Then you can escape the backslash in the rule for
the Unixy shell and not escape it in the rule for CMD. (Btw, the rule
for CMD should toss the quotes around the backslash as well, as the
`echo' command built into it does not remove quotes, and neither does
CMD itself.
The other possibility that occurred to me was using multiple macros
and string literal concatenation: [....]
This will also work, but the lists in $(OBJ0) etc. might be very long,
and there are shells on Windows that don't like too long command
lines. So I think the above alternative is better.