bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Harald Maier]

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

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Glenn Morris]

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.

Processed: Re: bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> merge 5167 5191
bug#5167: maximum command-line length assumed in Makefiles
bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
Merged 5167 5191.

> severity 5167 serious
Bug #5167 [emacs] maximum command-line length assumed in Makefiles
Bug #5191 [emacs] 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16
Severity set to 'serious' from 'normal'

Severity set to 'serious' from 'normal'

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Chong Yidong]

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:

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Chong Yidong]

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

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Glenn Morris]

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.

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Jan Djärv]

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

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Chong Yidong]

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.

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Dan Nicolaescu]

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.

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Chong Yidong]

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?

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Dan Nicolaescu]

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.

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Stefan Monnier]

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

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Eli Zaretskii]

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

bug#5191: 23.1.90; Make target compile-main fails under GNU/Linux Kernel 2.6.16

[Glenn Morris]

Version: 24.1

ELCFILES was removed, so this kind of thing won't happen in future.