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

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

[Ken Raeburn]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

As part of trying to make CANNOT_DUMP builds work better, I want to  
have the list of object files, currently written into buildobj.lst by  
make and read back by temacs during loadup, compiled into the  
executable instead.  (Snarf-documentation needs the list to know which  
bits of documentation to extract from the generated DOC file, since  
some symbols appear in multiple source files.)  I've created a simple  
patch to create a header file on UNIX that doc.c can include to get  
the list instead of opening a file and growing a buffer to read the  
contents into; it just needs to define one macro that expands to a  
string initializer.  I've made an attempt to write the changes for the  
Windows build process, but I don't currently have a machine to test  
them, especially with all the permutations of make versions and shells  
to run under them.

Could someone with the relevant expertise and/or equipment please take  
a minute and let me know the right way to make this change?  I think  
it should be pretty straightforward, as you can see from the changes  
in the attached diff, but it does involve make commands that have to  
write double-quotes and backslashes to files (and thus get the quoting  
right), and an object file list that is supposedly too long to process  
on one command line...

Ken



[-- Attachment #2: buildobj.diff --]
[-- Type: application/octet-stream, Size: 4965 bytes --]

Index: src/Makefile.in
===================================================================
RCS file: /sources/emacs/emacs/src/Makefile.in,v
retrieving revision 1.445
diff -p -u -r1.445 Makefile.in
--- src/Makefile.in	23 Aug 2009 04:43:12 -0000	1.445
+++ src/Makefile.in	23 Aug 2009 07:28:51 -0000
@@ -938,8 +938,10 @@ ${etc}DOC: ${libsrc}make-docfile${EXEEXT
 ${libsrc}make-docfile${EXEEXT}:
 	cd ${libsrc}; ${MAKE} ${MFLAGS} make-docfile${EXEEXT}
 
+buildobj.h: Makefile
+	echo "#define BUILDOBJ \"${obj} ${otherobj} " OBJECTS_MACHINE "\"" > buildobj.h
+
 temacs${EXEEXT}: $(LOCALCPP) $(STARTFILES) stamp-oldxmenu ${obj} ${otherobj} OBJECTS_MACHINE prefix-args${EXEEXT}
-	echo "${obj} ${otherobj} " OBJECTS_MACHINE > buildobj.lst
 #ifdef NS_IMPL_GNUSTEP
 	$(CC) -rdynamic YMF_PASS_LDFLAGS ( ${TEMACS_LDFLAGS} \
 	-L@GNUSTEP_SYSTEM_LIBRARIES@ -lgnustep-gui -lgnustep-base \
@@ -1064,7 +1066,8 @@ dispnew.o: dispnew.c systime.h commands.
    disptab.h indent.h $(INTERVALS_H) \
    xterm.h blockinput.h atimer.h character.h msdos.h composite.h keyboard.h \
    syssignal.h $(config_h)
-doc.o: doc.c $(config_h) epaths.h buffer.h keyboard.h keymap.h character.h
+doc.o: doc.c $(config_h) epaths.h buffer.h keyboard.h keymap.h character.h \
+   buildobj.h
 doprnt.o: doprnt.c character.h $(config_h)
 dosfns.o: buffer.h termchar.h termhooks.h frame.h blockinput.h window.h \
    msdos.h dosfns.h dispextern.h charset.h coding.h atimer.h systime.h \
@@ -1284,7 +1287,7 @@ mostlyclean:
 	rm -f temacs${EXEEXT} prefix-args${EXEEXT} core *.core \#* *.o libXMenu11.a liblw.a
 	rm -f ../etc/DOC
 	rm -f bootstrap-emacs${EXEEXT} emacs-${version}${EXEEXT}
-	rm -f buildobj.lst
+	rm -f buildobj.h
 clean: mostlyclean
 	rm -f emacs-*.*.*${EXEEXT} emacs${EXEEXT}
 #ifdef HAVE_NS
Index: src/doc.c
===================================================================
RCS file: /sources/emacs/emacs/src/doc.c,v
retrieving revision 1.134
diff -p -u -r1.134 doc.c
--- src/doc.c	8 Jan 2009 03:15:32 -0000	1.134
+++ src/doc.c	23 Aug 2009 07:28:51 -0000
@@ -42,6 +42,7 @@ along with GNU Emacs.  If not, see <http
 #include "keyboard.h"
 #include "character.h"
 #include "keymap.h"
+#include "buildobj.h"
 
 #ifdef HAVE_INDEX
 extern char *index P_ ((const char *, int));
@@ -552,6 +553,7 @@ store_function_docstring (fun, offset)
     }
 }
 
+static const char buildobj[] = BUILDOBJ;
 
 DEFUN ("Snarf-documentation", Fsnarf_documentation, Ssnarf_documentation,
        1, 1, 0,
@@ -598,32 +600,9 @@ the same file name is found in the `doc-
   /* Vbuild_files is nil when temacs is run, and non-nil after that.  */
   if (NILP (Vbuild_files))
   {
-    size_t cp_size = 0;
-    size_t to_read;
-    int nr_read;
-    char *cp = NULL;
-    char *beg, *end;
-
-    fd = emacs_open ("buildobj.lst", O_RDONLY, 0);
-    if (fd < 0)
-      report_file_error ("Opening file buildobj.lst", Qnil);
+    const char *beg, *end;
 
-    filled = 0;
-    for (;;)
-      {
-        cp_size += 1024;
-        to_read = cp_size - 1 - filled;
-        cp = xrealloc (cp, cp_size);
-        nr_read = emacs_read (fd, &cp[filled], to_read);
-        filled += nr_read;
-        if (nr_read < to_read)
-          break;
-      }
-
-    emacs_close (fd);
-    cp[filled] = 0;
-
-    for (beg = cp; *beg; beg = end)
+    for (beg = buildobj; *beg; beg = end)
       {
         int len;
 
@@ -639,8 +618,6 @@ the same file name is found in the `doc-
         if (len > 0)
           Vbuild_files = Fcons (make_string (beg, len), Vbuild_files);
       }
-
-    xfree (cp);
   }
 
   fd = emacs_open (name, O_RDONLY, 0);
Index: src/makefile.w32-in
===================================================================
RCS file: /sources/emacs/emacs/src/makefile.w32-in,v
retrieving revision 1.77
diff -p -u -r1.77 makefile.w32-in
--- src/makefile.w32-in	11 Mar 2009 01:02:07 -0000	1.77
+++ src/makefile.w32-in	23 Aug 2009 07:28:51 -0000
@@ -178,10 +178,16 @@ $(TEMACS):      $(TLIB0) $(TLIB1) $(TLIB
 		  ../nt/$(BLD)/addsection.exe
 	$(LINK) $(LINK_OUT)$(TEMACS_TMP) $(FULL_LINK_FLAGS) $(TOBJ) $(TRES) $(LIBS)
 	"../nt/$(BLD)/addsection" "$(TEMACS_TMP)" "$(TEMACS)" EMHEAP 21
-	echo $(OBJ0) > $(BLD)/buildobj.lst
-	echo $(OBJ1) >> $(BLD)/buildobj.lst
-	echo $(WIN32OBJ) >> $(BLD)/buildobj.lst
-	echo $(FONTOBJ) >> $(BLD)/buildobj.lst
+
+# This omits firstfile.${O}, but there's no documentation in there
+# anyways.
+$(SRC)/buildobj.h: Makefile
+	echo "#define BUILDOBJ \"\\"  > $(SRC)/buildobj.h
+	echo $(OBJ0)            "\\" >> $(SRC)/buildobj.h
+	echo $(OBJ1)            "\\" >> $(SRC)/buildobj.h
+	echo $(WIN32OBJ)        "\\" >> $(SRC)/buildobj.h
+	echo $(FONTOBJ)         "\\" >> $(SRC)/buildobj.h
+	echo "\""                    >> $(SRC)/buildobj.h
 
 bootstrap: bootstrap-emacs
 
@@ -580,6 +586,7 @@ $(BLD)/dispnew.$(O) : \
 $(BLD)/doc.$(O) : \
 	$(SRC)/doc.c \
 	$(CONFIG_H) \
+	$(SRC)/buildobj.h \
 	$(EMACS_ROOT)/nt/inc/unistd.h \
 	$(EMACS_ROOT)/nt/inc/sys/file.h \
 	$(EMACS_ROOT)/nt/inc/sys/time.h \

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]

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

[Jason Rumney]

Ken Raeburn wrote:
> I think it should be pretty straightforward, as you can see from the 
> changes in the attached diff, but it does involve make commands that 
> have to write double-quotes and backslashes to files (and thus get the 
> quoting right), and an object file list that is supposedly too long to 
> process on one command line...
To deal with quoting correctly for all variants of make/shell there are 
macros ARGQUOTE and DQUOTE.

I think the way you've broken up the object file list already should be 
OK, as it is following the previous code that you are replacing.  The 
object file sub-lists should be short enough not to break the line 
length limit on any of the shells that might be in use, and they should 
not be so close to the limit that a longer command will break them (if 
they are, we can fix that by rebalancing the object file sub-lists).

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

[Ken Raeburn]

On Aug 23, 2009, at 04:30, Jason Rumney wrote:
> Ken Raeburn wrote:
>> I think it should be pretty straightforward, as you can see from  
>> the changes in the attached diff, but it does involve make commands  
>> that have to write double-quotes and backslashes to files (and thus  
>> get the quoting right), and an object file list that is supposedly  
>> too long to process on one command line...
> To deal with quoting correctly for all variants of make/shell there  
> are macros ARGQUOTE and DQUOTE.

Ah...  I saw them, but didn't see very good examples until I looked  
more closely at some of the other (lisp, leim) makefile.w32-in files.   
So it looks like I should write the rules something like this?

	echo $(ARGQUOTE)#define BUILDOBJ $(DQUOTE)\$(ARGQUOTE)  > $(SRC)/ 
buildobj.h
	echo $(OBJ0)     $(ARGQUOTE)\$(ARGQUOTE) >> $(SRC)/buildobj.h

Is one backslash what I need here, if I want to get one written to the  
file at the end of the line?  Or does some backslash quote processing  
happen, and I need two?

Thanks!

Ken

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

[Jason Rumney]

Ken Raeburn wrote:
>
>     echo $(ARGQUOTE)#define BUILDOBJ $(DQUOTE)\$(ARGQUOTE)  > 
> $(SRC)/buildobj.h
>     echo $(OBJ0)     $(ARGQUOTE)\$(ARGQUOTE) >> $(SRC)/buildobj.h

Yes, that looks about right.

> Is one backslash what I need here, if I want to get one written to the 
> file at the end of the line?  Or does some backslash quote processing 
> happen, and I need two?

If you don't need to double the backslashes in the main Makefile.in, 
then I don't think it will be necessary here.  If you do need to double 
them in Makefile.in, then it is probably dependent on the shell in use, 
and we'll have to add some more definitions to correctly cope with the 
differences.

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

[Eli Zaretskii]

> Date: Mon, 24 Aug 2009 00:42:43 +0800
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Emacs Developers <emacs-devel@gnu.org>
> 
> Ken Raeburn wrote:
> >
> >     echo $(ARGQUOTE)#define BUILDOBJ $(DQUOTE)\$(ARGQUOTE)  > 
> > $(SRC)/buildobj.h
> >     echo $(OBJ0)     $(ARGQUOTE)\$(ARGQUOTE) >> $(SRC)/buildobj.h
> 
> Yes, that looks about right.
> 
> > Is one backslash what I need here, if I want to get one written to the 
> > file at the end of the line?  Or does some backslash quote processing 
> > happen, and I need two?
> 
> If you don't need to double the backslashes in the main Makefile.in, 
> then I don't think it will be necessary here.  If you do need to double 
> them in Makefile.in, then it is probably dependent on the shell in use, 
> and we'll have to add some more definitions to correctly cope with the 
> differences.

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.

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

[Ken Raeburn]

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

The other possibility that occurred to me was using multiple macros  
and string literal concatenation:

echo $(ARGQUOTE)#define  BUILDOBJ0 $(DQUOTE)$(OBJ0)$(DQUOTE)$ 
(ARGQUOTE) > $(SRC)/buildobj.h
...
echo $(ARGQUOTE)#define BUILDOBJ BUILDOBJ0 BUILDOBJ1 BUILDOBJWIN32  
BUILDOBJFONT$(ARGQUOTE) >> $(SRC)/buildobj.h

If all the compilers available for Windows (and useable for building  
Emacs) support this, it may be simpler than figuring out the backslash  
quoting issues.

Ken

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

[Eli Zaretskii]

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

> The other possibility that occurred to me was using multiple macros  
> and string literal concatenation:
> 
> echo $(ARGQUOTE)#define  BUILDOBJ0 $(DQUOTE)$(OBJ0)$(DQUOTE)$ 
> (ARGQUOTE) > $(SRC)/buildobj.h
> ...
> echo $(ARGQUOTE)#define BUILDOBJ BUILDOBJ0 BUILDOBJ1 BUILDOBJWIN32  
> BUILDOBJFONT$(ARGQUOTE) >> $(SRC)/buildobj.h
> 
> If all the compilers available for Windows (and useable for building  
> Emacs) support this, it may be simpler than figuring out the backslash  
> quoting issues.

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.

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

[Ken Raeburn]

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

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

[Eli Zaretskii]

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

Not with echo and not with other commands that are built into CMD.
Windows programs other than the shell do remove quotes from their
arguments, thus emulating some of the Unixy shell semantics, but CMD
does not.

> Is emacs itself processing the quotes?

No.

> 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 '"'?

Just stick '"'.  You don't need these variables when the shells are
separated in the first place.

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

[Ken Raeburn]

On Aug 23, 2009, at 23:19, Eli Zaretskii wrote:
> Not with echo and not with other commands that are built into CMD.
> Windows programs other than the shell do remove quotes from their
> arguments, thus emulating some of the Unixy shell semantics, but CMD
> does not.

Ah, that's the source of some of my confusion.  Thanks.

> Just stick '"'.  You don't need these variables when the shells are
> separated in the first place.

Good point.  I think I'm starting to understand. :-)
Though DQUOTE in SH mode seems to depend on NEW_CYGWIN, so I'll keep  
that...
Then, I think this should do it... does it look right to you?

$(SRC)/buildobj.h: make-buildobj-$(SHELLTYPE)
make-buildobj-CMD: Makefile
	echo #define BUILDOBJ "\  > $(SRC)/buildobj.h
	echo $(OBJ0)           \ >> $(SRC)/buildobj.h
	echo $(OBJ1)           \ >> $(SRC)/buildobj.h
	echo $(WIN32OBJ)       \ >> $(SRC)/buildobj.h
	echo $(FONTOBJ)        \ >> $(SRC)/buildobj.h
	echo "                   >> $(SRC)/buildobj.h
make-buildobj-SH: 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

Ken

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

[Eli Zaretskii]

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Mon, 24 Aug 2009 00:16:43 -0400
> Cc: jasonr@gnu.org, emacs-devel@gnu.org
> 
> Then, I think this should do it... does it look right to you?
> 
> $(SRC)/buildobj.h: make-buildobj-$(SHELLTYPE)
> make-buildobj-CMD: Makefile
> 	echo #define BUILDOBJ "\  > $(SRC)/buildobj.h
> 	echo $(OBJ0)           \ >> $(SRC)/buildobj.h
> 	echo $(OBJ1)           \ >> $(SRC)/buildobj.h
> 	echo $(WIN32OBJ)       \ >> $(SRC)/buildobj.h
> 	echo $(FONTOBJ)        \ >> $(SRC)/buildobj.h
> 	echo "                   >> $(SRC)/buildobj.h

The first and the last lines still don't work, because `echo' retains
the quotes, but still disables the special meaning of > and >> inside
quotes, and so redirection doesn't work.  I see no choice but to use
`^' to escape the quotes:

$(SRC)/buildobj.h: Makefile
	echo #define BUILDOBJ ^"\  > $(SRC)/buildobj.h
	echo $(OBJ0)           \ >> $(SRC)/buildobj.h
	echo $(OBJ1)           \ >> $(SRC)/buildobj.h
	echo $(WIN32OBJ)       \ >> $(SRC)/buildobj.h
	echo $(FONTOBJ)        \ >> $(SRC)/buildobj.h
	echo ^"                  >> $(SRC)/buildobj.h

(`^' is the CMD escape character, but only CMD supports it, Windows
programs do not, in general.  Sigh.)

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

[Ken Raeburn]

On Aug 24, 2009, at 14:22, Eli Zaretskii wrote:
> The first and the last lines still don't work, because `echo' retains
> the quotes, but still disables the special meaning of > and >> inside
> quotes, and so redirection doesn't work.  I see no choice but to use
> `^' to escape the quotes:

Ah, another bit of CMD syntax I wasn't familiar with.  Thanks!

> $(SRC)/buildobj.h: Makefile
> 	echo #define BUILDOBJ ^"\  > $(SRC)/buildobj.h
> 	echo $(OBJ0)           \ >> $(SRC)/buildobj.h
> 	echo $(OBJ1)           \ >> $(SRC)/buildobj.h
> 	echo $(WIN32OBJ)       \ >> $(SRC)/buildobj.h
> 	echo $(FONTOBJ)        \ >> $(SRC)/buildobj.h
> 	echo ^"                  >> $(SRC)/buildobj.h

This looks like just what I need, thanks.  With this, I think I can  
make the CANNOT_DUMP build cleanly load its documentation, without  
breaking the Windows build.

Ken