Subject: bug#8764: 24.0.50; cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'

From: Lars Ingebrigtsen <[email-masked]>
Date: Fri, 03 Dec 2021 22:20:54 +0100

Paul Eggert <[email-masked]> writes:

> One hypothesis is that c-by.el depends on some other .el file being
> compiled into *.elc form (rather than being present in only source
> form), and that using 'make -j5' causes 'make' on my platform to
> (unluckily) arrange for c-by.el to be compiled before the other *.elc
> file (whatever it is) is available.

I found a reproducer:

larsi@xo:~/src/emacs/trunk$ rm lisp/emacs-lisp/cconv.elc
larsi@xo:~/src/emacs/trunk$ ./src/emacs -batch --eval '(byte-compile-file "./lisp/cedet/semantic/bovine/c-by.el")'

In toplevel form:
lisp/cedet/semantic/bovine/c-by.el:198:1: Error: Lisp nesting exceeds ‘max-lisp-eval-depth’
larsi@xo:~/src/emacs/trunk$ ./src/emacs -batch --eval '(byte-compile-file "./lisp/emacs-lisp/cconv.el")'
larsi@xo:~/src/emacs/trunk$ ./src/emacs -batch --eval '(byte-compile-file "./lisp/cedet/semantic/bovine/c-by.el")'
larsi@xo:~/src/emacs/trunk$ 

And indeed:

larsi@xo:~/src/emacs/trunk$ rm lisp/emacs-lisp/cconv.elc lisp/cedet/semantic/bovine/c-by.elc
rm: cannot remove 'lisp/cedet/semantic/bovine/c-by.elc': No such file or directory
larsi@xo:~/src/emacs/trunk$ make -j8
make -C lib all
make -C doc/lispref info

[...]

make[2]: Entering directory '/home/larsi/src/emacs/trunk/lisp'
  ELC      emacs-lisp/cconv.elc
  ELC      cedet/semantic/bovine/c-by.elc

In toplevel form:
cedet/semantic/bovine/c-by.el:198:1: Error: Lisp nesting exceeds ‘max-lisp-eval-depth’
make[2]: *** [Makefile:312: cedet/semantic/bovine/c-by.elc] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/larsi/src/emacs/trunk/lisp'
make[1]: *** [Makefile:342: compile-main] Error 2
make[1]: Leaving directory '/home/larsi/src/emacs/trunk/lisp'
make: *** [Makefile:439: lisp] Error 2

Now, cconv.elc is already in COMPILE_FIRST...  and adding it to
MAIN_FIRST in addition doesn't seem to help.  It doesn't seem to
actually wait until compiling MAIN_FIRST is done before doing the rest?
(If I'm reading the Makefile correctly.)

Yup.  I've now separated out the MAIN_FIRST into its own target, and
that fixes this problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no