From: Ken Raeburn <raeburn@raeburn.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org, jasonr@gnu.org
Subject: Re: buildobj.lst and Windows builds - a tiny bit of help needed?
Date: Sun, 23 Aug 2009 17:07:04 -0400 [thread overview]
Message-ID: <80FD0395-33BC-4EBE-B84A-02C1B29783FB@raeburn.org> (raw)
In-Reply-To: <834oryffnu.fsf@gnu.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
next prev parent reply other threads:[~2009-08-23 21:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-23 7:50 buildobj.lst and Windows builds - a tiny bit of help needed? Ken Raeburn
2009-08-23 8:30 ` Jason Rumney
2009-08-23 10:48 ` Ken Raeburn
2009-08-23 16:42 ` Jason Rumney
2009-08-23 18:02 ` Eli Zaretskii
2009-08-23 18:43 ` Ken Raeburn
2009-08-23 20:17 ` Eli Zaretskii
2009-08-23 21:07 ` Ken Raeburn [this message]
2009-08-24 3:19 ` Eli Zaretskii
2009-08-24 4:16 ` Ken Raeburn
2009-08-24 18:22 ` Eli Zaretskii
2009-08-26 7:08 ` Ken Raeburn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80FD0395-33BC-4EBE-B84A-02C1B29783FB@raeburn.org \
--to=raeburn@raeburn.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jasonr@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.