* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
@ 2009-12-12 10:28 Harald Maier
2009-12-12 19:45 ` Glenn Morris
0 siblings, 1 reply; 13+ messages in thread
From: Harald Maier @ 2009-12-12 10:28 UTC (permalink / raw)
To: emacs-pretest-bug
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list,
and to the gnu.emacs.bug news group.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug. If you can, give
a recipe starting from `emacs -Q':
With the checkout today the build failed on a GNU/Linux Kernel
2.6.16. The problem ist the make target "compile-main" in the lisp
directory.
$ LANG=en_US make compile-main
make[1]: Entering directory `/home/maierh/build/cvs/emacs/lisp'
make[1]: execvp: echo: Argument list too long
make[1]: *** [/home/maierh/build/cvs/emacs/lisp/mh-e/mh-alias.elc] Error 127
make[1]: Leaving directory `/home/maierh/build/cvs/emacs/lisp'
make: *** [compile-main] Error 2
Harald
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/local/share/emacs/23.1.90/etc/DEBUG.
In GNU Emacs 23.1.90.1 (i686-pc-linux-gnu, GTK+ Version 2.8.11)
of 2009-12-12 on nyx-s10
Windowing system distributor `The X.Org Foundation', version 11.0.60900000
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: de_DE.UTF-8
value of $XMODIFIERS: @im=local
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-12 10:28 Harald Maier
@ 2009-12-12 19:45 ` Glenn Morris
0 siblings, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2009-12-12 19:45 UTC (permalink / raw)
To: 5191
merge 5167 5191
severity 5167 serious
stop
Harald Maier wrote:
> $ LANG=en_US make compile-main
> make[1]: Entering directory `/home/maierh/build/cvs/emacs/lisp'
> make[1]: execvp: echo: Argument list too long
This answers my question from bug#5167.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
@ 2009-12-12 20:24 Chong Yidong
2009-12-12 21:40 ` Jan Djärv
2009-12-15 4:21 ` Stefan Monnier
0 siblings, 2 replies; 13+ messages in thread
From: Chong Yidong @ 2009-12-12 20:24 UTC (permalink / raw)
To: Harald Maier; +Cc: 5191
Does this patch fix it? Instead of passing ELCFILES on the command
line, it saves it to a .elcfiles file, and the recursive Make includes
that. (I am assuming the "-include" directive is supported, but we seem
to use it in src/Makefile already anyhow.)
*** emacs/lisp/Makefile.in.~1.215.~ 2009-12-09 09:21:04.000000000 -0500
--- emacs/lisp/Makefile.in 2009-12-12 15:13:02.000000000 -0500
***************
*** 211,216 ****
--- 211,218 ----
compile-first: $(COMPILE_FIRST)
+ -include $(lisp)/.elcfiles
+
# ELCFILES is set dynamically in the recursive call from `compile-main'.
compile-elcfiles: $(ELCFILES)
***************
*** 219,230 ****
compile-main:
@wd=$(lisp); $(setwins); \
els=`echo "$$wins " | sed -e 's|/\./|/|g' -e 's|/\. | |g' -e 's| |/*.el |g'`; \
for el in $$els; do \
test -f $$el || continue; \
test ! -f $${el}c && GREP_OPTIONS= grep '^;.*no-byte-compile: t' $$el > /dev/null && continue; \
! files="$$files $${el}c"; \
done; \
! $(MAKE) $(MFLAGS) compile-elcfiles EMACS=$(EMACS) ELCFILES="$$files"
# Erase left-over .elc files that do not have a corresponding .el file.
compile-clean:
--- 221,233 ----
compile-main:
@wd=$(lisp); $(setwins); \
els=`echo "$$wins " | sed -e 's|/\./|/|g' -e 's|/\. | |g' -e 's| |/*.el |g'`; \
+ echo -n "ELCFILES=" > $(lisp)/.elcfiles; \
for el in $$els; do \
test -f $$el || continue; \
test ! -f $${el}c && GREP_OPTIONS= grep '^;.*no-byte-compile: t' $$el > /dev/null && continue; \
! echo -n "$${el}c " >> $(lisp)/.elcfiles; \
done; \
! $(MAKE) $(MFLAGS) compile-elcfiles EMACS=$(EMACS)
# Erase left-over .elc files that do not have a corresponding .el file.
compile-clean:
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
@ 2009-12-12 21:00 Chong Yidong
2009-12-12 21:07 ` Glenn Morris
0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2009-12-12 21:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Harald Maier, 5191
> Does this patch fix it? Instead of passing ELCFILES on the command
> line, it saves it to a .elcfiles file, and the recursive Make includes
> that. (I am assuming the "-include" directive is supported, but we seem
> to use it in src/Makefile already anyhow.)
On second thought, I don't think this is a good idea. Looks like the
BSDs use ".sinclude" for silent inclusion, and older systems don't even
support that.
If no better plan is forthcoming that can simultaneously cope with
ARG_MAX limitations and cross-Unix incompatibilities, I think it's
better to revert Makefile.in to the "ELCFILES abomination". We can live
with it for a while longer.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-12 21:00 bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16 Chong Yidong
@ 2009-12-12 21:07 ` Glenn Morris
2009-12-14 23:29 ` Chong Yidong
0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2009-12-12 21:07 UTC (permalink / raw)
To: Chong Yidong; +Cc: Harald Maier, 5191
Chong Yidong wrote:
> On second thought, I don't think this is a good idea. Looks like the
> BSDs use ".sinclude" for silent inclusion, and older systems don't even
> support that.
I think you are right that include is not portable. It's currently
only used in GNUstep builds. I don't think "echo -n" is portable
either. "printf" might be better, I'm not sure.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-12 20:24 Chong Yidong
@ 2009-12-12 21:40 ` Jan Djärv
2009-12-15 4:21 ` Stefan Monnier
1 sibling, 0 replies; 13+ messages in thread
From: Jan Djärv @ 2009-12-12 21:40 UTC (permalink / raw)
To: Chong Yidong, 5191; +Cc: Harald Maier
Chong Yidong skrev 2009-12-12 21.24:
> Does this patch fix it? Instead of passing ELCFILES on the command
> line, it saves it to a .elcfiles file, and the recursive Make includes
> that. (I am assuming the "-include" directive is supported, but we seem
> to use it in src/Makefile already anyhow.)
Note that in src/Makefile we only use it if we know we are using GNU Make.
Configure tests for GNU Make.
Jan D.
>
> *** emacs/lisp/Makefile.in.~1.215.~ 2009-12-09 09:21:04.000000000 -0500
> --- emacs/lisp/Makefile.in 2009-12-12 15:13:02.000000000 -0500
> ***************
> *** 211,216 ****
> --- 211,218 ----
>
> compile-first: $(COMPILE_FIRST)
>
> + -include $(lisp)/.elcfiles
> +
> # ELCFILES is set dynamically in the recursive call from `compile-main'.
> compile-elcfiles: $(ELCFILES)
>
> ***************
> *** 219,230 ****
> compile-main:
> @wd=$(lisp); $(setwins); \
> els=`echo "$$wins " | sed -e 's|/\./|/|g' -e 's|/\. | |g' -e 's| |/*.el |g'`; \
> for el in $$els; do \
> test -f $$el || continue; \
> test ! -f $${el}c&& GREP_OPTIONS= grep '^;.*no-byte-compile: t' $$el> /dev/null&& continue; \
> ! files="$$files $${el}c"; \
> done; \
> ! $(MAKE) $(MFLAGS) compile-elcfiles EMACS=$(EMACS) ELCFILES="$$files"
>
> # Erase left-over .elc files that do not have a corresponding .el file.
> compile-clean:
> --- 221,233 ----
> compile-main:
> @wd=$(lisp); $(setwins); \
> els=`echo "$$wins " | sed -e 's|/\./|/|g' -e 's|/\. | |g' -e 's| |/*.el |g'`; \
> + echo -n "ELCFILES="> $(lisp)/.elcfiles; \
> for el in $$els; do \
> test -f $$el || continue; \
> test ! -f $${el}c&& GREP_OPTIONS= grep '^;.*no-byte-compile: t' $$el> /dev/null&& continue; \
> ! echo -n "$${el}c ">> $(lisp)/.elcfiles; \
> done; \
> ! $(MAKE) $(MFLAGS) compile-elcfiles EMACS=$(EMACS)
>
> # Erase left-over .elc files that do not have a corresponding .el file.
> compile-clean:
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-12 21:07 ` Glenn Morris
@ 2009-12-14 23:29 ` Chong Yidong
2009-12-15 0:28 ` Dan Nicolaescu
0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2009-12-14 23:29 UTC (permalink / raw)
To: Glenn Morris; +Cc: Harald Maier, 5191
Glenn Morris <rgm@gnu.org> writes:
> Chong Yidong wrote:
>
>> On second thought, I don't think this is a good idea. Looks like the
>> BSDs use ".sinclude" for silent inclusion, and older systems don't even
>> support that.
>
> I think you are right that include is not portable. It's currently
> only used in GNUstep builds. I don't think "echo -n" is portable
> either. "printf" might be better, I'm not sure.
Another idea: how about autogenerating the ELCFILES Makefile using
configure? Then Makefile.in could just have a line that says
ELCFILES=@elcfiles@
where @elcfiles@ is generated by configure.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-14 23:29 ` Chong Yidong
@ 2009-12-15 0:28 ` Dan Nicolaescu
2009-12-15 2:26 ` Chong Yidong
0 siblings, 1 reply; 13+ messages in thread
From: Dan Nicolaescu @ 2009-12-15 0:28 UTC (permalink / raw)
To: Chong Yidong; +Cc: Harald Maier, 5191
Chong Yidong <cyd@stupidchicken.com> writes:
> Glenn Morris <rgm@gnu.org> writes:
>
> > Chong Yidong wrote:
> >
> >> On second thought, I don't think this is a good idea. Looks like the
> >> BSDs use ".sinclude" for silent inclusion, and older systems don't even
> >> support that.
> >
> > I think you are right that include is not portable. It's currently
> > only used in GNUstep builds. I don't think "echo -n" is portable
> > either. "printf" might be better, I'm not sure.
>
> Another idea: how about autogenerating the ELCFILES Makefile using
> configure? Then Makefile.in could just have a line that says
>
> ELCFILES=@elcfiles@
>
> where @elcfiles@ is generated by configure.
Yet another idea: how about we require GNU make?
Other GNU projects require GNU make already, like GCC.
GNU make is widely available on all free systems, and even on
proprietary unixes, I've personally never seen a machine used for
software development that did not have GNU make.
We can float the idea in the 23.2 release, and make it mandatory a few
months after if we don't get significant pushback.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-15 0:28 ` Dan Nicolaescu
@ 2009-12-15 2:26 ` Chong Yidong
2009-12-15 3:11 ` Dan Nicolaescu
0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2009-12-15 2:26 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: Harald Maier, 5191
Dan Nicolaescu <dann@ics.uci.edu> writes:
> Yet another idea: how about we require GNU make? Other GNU projects
> require GNU make already, like GCC. GNU make is widely available on
> all free systems, and even on proprietary unixes, I've personally
> never seen a machine used for software development that did not have
> GNU make.
What about the BSDs? My impression is that they still use their own
Make version, no?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-15 2:26 ` Chong Yidong
@ 2009-12-15 3:11 ` Dan Nicolaescu
0 siblings, 0 replies; 13+ messages in thread
From: Dan Nicolaescu @ 2009-12-15 3:11 UTC (permalink / raw)
To: Chong Yidong; +Cc: Harald Maier, 5191
Chong Yidong <cyd@stupidchicken.com> writes:
> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
> > Yet another idea: how about we require GNU make? Other GNU projects
> > require GNU make already, like GCC. GNU make is widely available on
> > all free systems, and even on proprietary unixes, I've personally
> > never seen a machine used for software development that did not have
> > GNU make.
>
> What about the BSDs? My impression is that they still use their own
> Make version, no?
They do, but GNU make is still readily available.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-12 20:24 Chong Yidong
2009-12-12 21:40 ` Jan Djärv
@ 2009-12-15 4:21 ` Stefan Monnier
2009-12-15 5:36 ` Eli Zaretskii
1 sibling, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2009-12-15 4:21 UTC (permalink / raw)
To: Chong Yidong; +Cc: Harald Maier, 5191
> + -include $(lisp)/.elcfiles
This is sadly not portable.
We could indeed put the list of elcfiles in a file, and then use
xargs make <.elcfiles
-- Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-15 4:21 ` Stefan Monnier
@ 2009-12-15 5:36 ` Eli Zaretskii
2011-03-10 1:49 ` Glenn Morris
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2009-12-15 5:36 UTC (permalink / raw)
To: Stefan Monnier, 5191; +Cc: cyd, Harald, 5191
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 14 Dec 2009 23:21:23 -0500
> Cc: Harald Maier <Harald@Maierh.de>, 5191@emacsbugs.donarmstrong.com
> Reply-To: Stefan Monnier <monnier@IRO.UMontreal.CA>,
> 5191@emacsbugs.donarmstrong.com
>
> > + -include $(lisp)/.elcfiles
>
> This is sadly not portable.
> We could indeed put the list of elcfiles in a file, and then use
>
> xargs make <.elcfiles
If we eventually decide to go this way, please don't use a file name
that begins with a dot: apart of being disallowed on DOS filesystems,
such a file is hidden from `ls' and other commands, which in this case
does not seem to be justified, since this is a file generated by the
build.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
2009-12-15 5:36 ` Eli Zaretskii
@ 2011-03-10 1:49 ` Glenn Morris
0 siblings, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2011-03-10 1:49 UTC (permalink / raw)
To: 5191-done
Version: 24.1
ELCFILES was removed, so this kind of thing won't happen in future.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-03-10 1:49 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-12 21:00 bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16 Chong Yidong
2009-12-12 21:07 ` Glenn Morris
2009-12-14 23:29 ` Chong Yidong
2009-12-15 0:28 ` Dan Nicolaescu
2009-12-15 2:26 ` Chong Yidong
2009-12-15 3:11 ` Dan Nicolaescu
-- strict thread matches above, loose matches on Subject: below --
2009-12-12 20:24 Chong Yidong
2009-12-12 21:40 ` Jan Djärv
2009-12-15 4:21 ` Stefan Monnier
2009-12-15 5:36 ` Eli Zaretskii
2011-03-10 1:49 ` Glenn Morris
2009-12-12 10:28 Harald Maier
2009-12-12 19:45 ` Glenn Morris
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).