* buildobj.lst and Windows builds - a tiny bit of help needed?
@ 2009-08-23 7:50 Ken Raeburn
2009-08-23 8:30 ` Jason Rumney
0 siblings, 1 reply; 12+ messages in thread
From: Ken Raeburn @ 2009-08-23 7:50 UTC (permalink / raw)
To: Emacs Developers
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
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
0 siblings, 1 reply; 12+ messages in thread
From: Jason Rumney @ 2009-08-23 8:30 UTC (permalink / raw)
To: Ken Raeburn; +Cc: Emacs Developers
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).
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-23 8:30 ` Jason Rumney
@ 2009-08-23 10:48 ` Ken Raeburn
2009-08-23 16:42 ` Jason Rumney
0 siblings, 1 reply; 12+ messages in thread
From: Ken Raeburn @ 2009-08-23 10:48 UTC (permalink / raw)
To: Jason Rumney; +Cc: Emacs Developers
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-23 10:48 ` Ken Raeburn
@ 2009-08-23 16:42 ` Jason Rumney
2009-08-23 18:02 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Jason Rumney @ 2009-08-23 16:42 UTC (permalink / raw)
To: Ken Raeburn; +Cc: Emacs Developers
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-23 16:42 ` Jason Rumney
@ 2009-08-23 18:02 ` Eli Zaretskii
2009-08-23 18:43 ` Ken Raeburn
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2009-08-23 18:02 UTC (permalink / raw)
To: Jason Rumney; +Cc: raeburn, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-23 18:02 ` Eli Zaretskii
@ 2009-08-23 18:43 ` Ken Raeburn
2009-08-23 20:17 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Ken Raeburn @ 2009-08-23 18:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, Jason Rumney
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-23 18:43 ` Ken Raeburn
@ 2009-08-23 20:17 ` Eli Zaretskii
2009-08-23 21:07 ` Ken Raeburn
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2009-08-23 20:17 UTC (permalink / raw)
To: Ken Raeburn; +Cc: emacs-devel, jasonr
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-23 20:17 ` Eli Zaretskii
@ 2009-08-23 21:07 ` Ken Raeburn
2009-08-24 3:19 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Ken Raeburn @ 2009-08-23 21:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, jasonr
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-23 21:07 ` Ken Raeburn
@ 2009-08-24 3:19 ` Eli Zaretskii
2009-08-24 4:16 ` Ken Raeburn
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2009-08-24 3:19 UTC (permalink / raw)
To: Ken Raeburn; +Cc: emacs-devel, jasonr
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-24 3:19 ` Eli Zaretskii
@ 2009-08-24 4:16 ` Ken Raeburn
2009-08-24 18:22 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Ken Raeburn @ 2009-08-24 4:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, jasonr
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-24 4:16 ` Ken Raeburn
@ 2009-08-24 18:22 ` Eli Zaretskii
2009-08-26 7:08 ` Ken Raeburn
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2009-08-24 18:22 UTC (permalink / raw)
To: Ken Raeburn; +Cc: emacs-devel, jasonr
> 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.)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: buildobj.lst and Windows builds - a tiny bit of help needed?
2009-08-24 18:22 ` Eli Zaretskii
@ 2009-08-26 7:08 ` Ken Raeburn
0 siblings, 0 replies; 12+ messages in thread
From: Ken Raeburn @ 2009-08-26 7:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, jasonr
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-08-26 7:08 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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.