automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] When computing lispdir, don't load emacs site wide init file


From: Stefano Lattarini
Subject: Re: [PATCH] When computing lispdir, don't load emacs site wide init file.
Date: Fri, 19 Dec 2014 21:23:32 +0100

On 07/30/2014 06:41 PM, Andrew Burgess wrote:
I ran into an issue recently where a ./configure on autoconf failed
at this stage 'checking where .elc files should go...'.

I investigated a little and found the problem was that this shell
command:
   emacs -batch -q -eval '(while load-path (princ (concat (car
             load-path) "\n")) (setq load-path (cdr load-path)))'
hangs on my system; the above command originates from
automake/m4/lispdir.m4.

The root cause is that an emacs package loaded from the site-wide
initialisation file causes a second package to auto-load when emacs
exits.  If the second, auto-loaded package is not found then emacs
hangs.

It turns out this is probably an emacs bug (and also the package in
question, autocomplete, should probably not load itself when in batch
mode), however, if automake switched from using '-q' to '-Q' in the
previous command then the site wide initialisation file would not be
loaded, and the problem would go away.  This feels like a pretty easy
win... what do you think?

Patch and proposed commit message below, feel free to use as you see
fit.

Thanks,
Andrew


--

When computing the lispdir emacs was previously invoked with the '-q'
option to avoid loading the users initialisation files, however, the
site wide initialisation file was still loaded, in some cases this can
cause emacs to hang, with the result that a configure can also hang.

The lisp code that aclocal causes to be executed reduces the load-path
list (in emacs) to empty.  The load-path is used by emacs to find
packages which it wants to load.  Currently, if emacs tries to auto
load a package during shut down, and the package is not found, then
emacs will hang.  This does seem like an emacs bug, but protecting
against this in aclocal is simply a case of not loading the site wide
initialisation file.

In this patch then the '-q' option to emacs is replaced with '-Q',
this has the same, the '-Q' option is similar to '-q --no-site-file
--no-splash'.

        * doc/automake.texi (Hard-Coded Install Paths): Update
        * explanation of emacs code used to get lispdir.
        * m4/lispdir.m4 (AM_PATH_LISPDIR): Update emacs flags.
---
  doc/automake.texi | 2 +-
  m4/lispdir.m4     | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index fa22517..25330ca 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -12904,7 +12904,7 @@ instance, here is how @code{AM_PATH_LISPDIR} 
(@pxref{Emacs Lisp})
  computes @samp{$(lispdir)}:

  @example
-$EMACS -batch -q -eval '(while load-path
+$EMACS -batch -Q -eval '(while load-path
    (princ (concat (car load-path) "\n"))
    (setq load-path (cdr load-path)))' >conftest.out
  lispdir=`sed -n
diff --git a/m4/lispdir.m4 b/m4/lispdir.m4
index 95a88da..f1f2212 100644
--- a/m4/lispdir.m4
+++ b/m4/lispdir.m4
@@ -34,7 +34,7 @@ AC_DEFUN([AM_PATH_LISPDIR],
    #  which is non-obvious for non-emacs users.
    # Redirecting /dev/null should help a bit; pity we can't detect "broken"
    #  emacsen earlier and avoid running this altogether.
-  AC_RUN_LOG([$EMACS -batch -q -eval '(while load-path (princ (concat (car load-path) 
"\n")) (setq load-path (cdr load-path)))' </dev/null >conftest.out])
+  AC_RUN_LOG([$EMACS -batch -Q -eval '(while load-path (princ (concat (car load-path) 
"\n")) (setq load-path (cdr load-path)))' </dev/null >conftest.out])
        am_cv_lispdir=`sed -n \
         -e 's,/$,,' \
         -e 
'/.*\/lib\/x*emacs\/site-lisp$/{s,.*/lib/\(x*emacs/site-lisp\)$,${libdir}/\1,;p;q;}'
 \

Thanks, patch applied (with apologies for the delay).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]