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

[DJ Lucas]

On 11/27/2011 07:19 AM, Bruno Haible wrote:
> Hi,
>
> DJ Lucas wrote:
> > The configure script ignores the "--without-emacs" switch if the EMACS
> > variable is set in the calling environment. If the user overrides this,
> > then the variable is set to no, however, the LISPDIR is checked before
> > evaluating withval (causing errors). The correct fix is to not check the
> > LISPDIR if EMACS is set to no. See trivial diff attached.
> The diff is OK, but your description of what it does was incorrect:
> The configure script does *not* ignore the "--without-emacs" option
> if the EMACS environment variable is set. Also, the determination of
> lispdir does not provoke errors (at least if you set the EMACS environment
> variable to point to a working emacs program).
>
> I tested the results in config.status.
Yes, my previous evaluation of the problem was incorrect. 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 (for which I was 
only testing to see if it was a suitable bootstrap distro). I'm not sure 
what other distros out there use zile, or if it is only a problem with 
Gentoo's build of GNU Zile (one of the other reports I noticed is System 
Rescue CD which I found is also Gentoo based). It is curious that it did 
not seem to fail on the x86 disc, of course I wasn't looking for it 
either. I'll go back a little later and verify that the x86 disc works 
and alert the Gentoo developers if necessary.

Regardless, putting things in the correct order alleviates the problem 
in this case (so long as AM_PATH_LISPDIR is put into a conditional), and 
likely fixes the other cases that I ran across in Google searches, but 
never found a 'fix.'

Thanks for the quick response.

-- DJ Lucas


--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.