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

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