From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: buildobj.lst and Windows builds - a tiny bit of help needed? Date: Sun, 23 Aug 2009 17:07:04 -0400 Message-ID: <80FD0395-33BC-4EBE-B84A-02C1B29783FB@raeburn.org> References: <4CC1CF5E-088F-459E-BCF7-61DEFA747DE1@raeburn.org> <4A90FE29.9080205@gnu.org> <72B7514B-A488-4FA1-A0C6-8114E60E9209@raeburn.org> <4A917183.9090404@gnu.org> <83bpm6flxx.fsf@gnu.org> <834oryffnu.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1251061690 7953 80.91.229.12 (23 Aug 2009 21:08:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Aug 2009 21:08:10 +0000 (UTC) Cc: emacs-devel@gnu.org, jasonr@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 23 23:08:03 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MfKIF-00087s-4n for ged-emacs-devel@m.gmane.org; Sun, 23 Aug 2009 23:08:03 +0200 Original-Received: from localhost ([127.0.0.1]:35853 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfKIE-0002AP-Jr for ged-emacs-devel@m.gmane.org; Sun, 23 Aug 2009 17:08:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MfKHb-0001Ys-MK for emacs-devel@gnu.org; Sun, 23 Aug 2009 17:07:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MfKHW-0001SG-UM for emacs-devel@gnu.org; Sun, 23 Aug 2009 17:07:23 -0400 Original-Received: from [199.232.76.173] (port=36870 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfKHW-0001Rw-GT for emacs-devel@gnu.org; Sun, 23 Aug 2009 17:07:18 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:39496 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MfKHK-0005Po-75; Sun, 23 Aug 2009 17:07:14 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n7NL74T8024130; Sun, 23 Aug 2009 17:07:04 -0400 (EDT) In-Reply-To: <834oryffnu.fsf@gnu.org> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114537 Archived-At: On Aug 23, 2009, at 16:17, Eli Zaretskii wrote: >> From: Ken Raeburn >> Date: Sun, 23 Aug 2009 14:43:04 -0400 >> Cc: Jason Rumney , 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