GNU bug report logs - #66111
is there a problem with --prefix?

Previous Next

Full log

View this message in rfc822 format

From: Ambrose Kofi Laing <aklaing <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66111 <at> debbugs.gnu.org
Subject: bug#66111: is there a problem with --prefix?
Date: Wed, 20 Sep 2023 13:04:02 -0400

[Message part 1 (text/plain, inline)]

Hi Eli,

Thanks for your response.  I was indeed building from the tarball.

I commented out the autogen.sh call, and still the installation went into
/usr/local, instead of to the /nonstandard/location.  So that was not the
only
problem.  After fiddling with it some more I discovered the following
(sequence of errors):

- One of the arguments to my configure script was: --with-tree-sitter

- libtree-sitter-dev was not available on my system [First Mistake]

- I was running configure inside a bash shell script, and I had not put "set
  -e" at the top of that bash script. [Second Mistake]

- As a result, configure correctly detected that libtree-sitter was missing
and failed (and did not produce a Makefile).

- Since I hadn't "set -e", the bash script went on ahead to run make anyway,
  instead of stopping right there.

- make did not find a Makefile, but found a GNUMakefile, and since there was
  no Makefile, make ran configure (without arguments) to generate a
Makefile,
  and naturally this invocation of configure did not include my setting of
  --prefix=/nonstandard/location from the previous call which failed.

- Finally when the install happened, it went into /usr/local instead of
  /nonstandard/location.

- To fix, this, I have to provide  tree-sitter obviously, but the quick
  fix was to remove --with-tree-sitter from the arguments of configure.

- Once that was done, configure ran correctly and generated a Makefile, I
  would assume including my setting of /nonstandard/location.  By this time
I had removed the autogen.sh call.

- Then running configure and make and make install installed correctly to
  /nonstandard/location.

So technically there is nothing wrong, but I can't help wondering if it
would
not be more helpful for the GNUMakefile to echo a message saying "I can't
find
a Makefile, please run configure yourself to generate one", instead of being
helpful and trying to run configure for me and not quite doing it the way I
wanted.  I know however that things like GNUMakefiles have a lot of history
and this behavior is probably unlikely to change.

Anyway, I'm all set now, thank you for your help!!

Best,

Ambrose

On Wed, Sep 20, 2023 at 8:30 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ambrose Kofi Laing <aklaing <at> gmail.com>
> > Date: Tue, 19 Sep 2023 13:59:26 -0400
> >
> > I'm trying to install emacs_29.1 at a nonstandard location, with the
> following commands:
> >
> >  cd src/emacs-29.1
> >  ./autogen.sh
> >  ./configure --prefix=/home/myname/my/custom/emacs29
> --with-native-compilation=aot -
> >  -with-imagemagick --with-json --with-tree-sitter --with-xft
> --without-compress-install
> >  make -j 4
> >
> > and I get an error message because of permission denied while trying to
> write under /usr/local (that is
> > where the script stops).  In addition, there are two locations where it
> says the following:
> >
> > make -C src BIN_DESTDIR=''/usr/local/bin/'' \
> > ELN_DESTDIR='/usr/local/lib/emacs/29.1/' all
>
> I don't see how this could have happened.  BIN_DESTDIR and ELN_DESTDIR
> are set in the top-level Makefile.ion like this:
>
>   ifeq (${ns_self_contained},no)
>   BIN_DESTDIR='$(DESTDIR)${bindir}/'
>   ELN_DESTDIR = $(DESTDIR)${libdir}/emacs/${version}/
>   else
>   BIN_DESTDIR='${ns_appbindir}/'
>   ELN_DESTDIR = ${ns_applibdir}/
>   endif
>
> Are you building the NS build on macOS?  If not, the upper part of the
> conditional above should be true for you, and the values should have
> obeyed the --prefix value you used at configure time.
>
> However, I don't understand why you ran autogen.sh.  Are you building
> from the Emacs 29.1 release tarball?  If so, the configure script is
> already produced and provided in the tarball, you just need to run it.
> Could you please unpack the Emacs 29.1 tarball in a fresh directory,
> run the configure script without running autogen.sh, and then say
> "make" and "make install", and see if the problem still happens.
>
> > This happens twice (please see below the ps under my signature for the
> full transcript of "make
> > install" to see the exact context in which it happens).  It seems to be
> that the --prefix does not override
> > certain locations that it is supposed to?
>
> It should, and I see the code to do that in Makefile.in, so I wonder
> why it didn't happen for you.
>
> > Are there other variables I need to set (other than the --prefix option
> to configure) that will ensure that
> > the compilation and installation will not try to write under /usr/local ?
>
> Please show the part of top-level Makefile where bindir and other
> variables are set.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.