Re: buildobj.lst and Windows builds - a tiny bit of help needed?

[Ken Raeburn <raeburn@raeburn.org>]

On Aug 23, 2009, at 16:17, Eli Zaretskii wrote:

>> From: Ken Raeburn <raeburn@raeburn.org>
>> Date: Sun, 23 Aug 2009 14:43:04 -0400
>> Cc: Jason Rumney <jasonr@gnu.org>, emacs-devel@gnu.org
>>
>> 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.

Then I think I misunderstand how $(ARGQUOTE) is supposed to be used,  
or how it's interpreted.  It gets used a lot with invocations of  
emacs, but shouldn't be with echo?  Is emacs itself processing the  
quotes?

Is this better?

$(SRC)/buildobj.h: make-buildobj-$(SHELLTYPE)
make-buildobj-CMD: Makefile
	echo #define BUILDOBJ $(DQUOTE)\  > $(SRC)/buildobj.h
	echo $(OBJ0)     \ >> $(SRC)/buildobj.h
	echo $(OBJ1)     \ >> $(SRC)/buildobj.h
	echo $(WIN32OBJ) \ >> $(SRC)/buildobj.h
	echo $(FONTOBJ)  \ >> $(SRC)/buildobj.h
	echo $(DQUOTE)     >> $(SRC)/buildobj.h
make-buildobj-SH: Makefile
	echo $(ARGQUOTE)#define BUILDOBJ $(DQUOTE)\\$(ARGQUOTE)  > $(SRC)/ 
buildobj.h
	echo $(OBJ0)     $(ARGQUOTE)\\$(ARGQUOTE) >> $(SRC)/buildobj.h
	echo $(OBJ1)     $(ARGQUOTE)\\$(ARGQUOTE) >> $(SRC)/buildobj.h
	echo $(WIN32OBJ) $(ARGQUOTE)\\$(ARGQUOTE) >> $(SRC)/buildobj.h
	echo $(FONTOBJ)  $(ARGQUOTE)\\$(ARGQUOTE) >> $(SRC)/buildobj.h
	echo $(ARGQUOTE)$(DQUOTE)$(ARGQUOTE)     >> $(SRC)/buildobj.h

But DQUOTE is '\"' for CMD; should the backslash be used there or  
should I just stick in a raw '"'?

>> 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.

Right, that's why the make rules would only use one such list per  
command, and rely on the compiler to join the C string versions; no  
backslashes needed.  It's looking like the better choice to me....

Ken