Re: [bug-gettext] [Patch] - Configure ignores --without-emacs setting if EMACS set

[Bruno Haible]

DJ Lucas wrote:
> In your above 
> text "*working* emacs program" is the kicker I believe. I'm not an emacs 
> user, so I guess I was a little careless in getting gettext to build 
> properly. The problem was that the --without-emacs is evaluated after 
> the check for the location of the elc files, which causes configure to 
> hang (I found several reports of this, but no fix, and no usable pattern 
> to follow). The only confirmed case *I* have of that, however, is if 
> /usr/bin/emacs -> zile on the Gentoo x86_64 Live DVD

Yup, the code in AM_PATH_LISPDIR is known to be dangerous:

  # If $EMACS isn't GNU Emacs or XEmacs, this can blow up pretty badly
  # Some emacsen will start up in interactive mode, requiring C-x C-c to exit,
  #  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.
  { { $as_echo "$as_me:${as_lineno-$LINENO}: \$EMACS -batch -q -eval '(while 
load-path (princ (concat (car load-path) \"\\n\")) (setq load-path (cdr 
load-path)))' </dev/null >conftest.out"; } >&5
  ($EMACS -batch -q -eval '(while load-path (princ (concat (car load-path) 
"\n")) (setq load-path (cdr load-path)))' </dev/null >conftest.out) 2>&5

Maybe you can write to bug-automake, and ask whether AM_PATH_LISPDIR can
be made more robust? The known workaround for a user would be to set EMACS=no
in the environment before running configure, but a solution that would
work without user intervention would be better.

Bruno
-- 
In memoriam George Moscone <http://en.wikipedia.org/wiki/George_Moscone>