unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ambrose Kofi Laing <aklaing@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 66111@debbugs.gnu.org
Subject: bug#66111: is there a problem with --prefix?
Date: Wed, 20 Sep 2023 13:04:02 -0400	[thread overview]
Message-ID: <CAD9Vp+69vS-B7YHwsq4ybc3krjJw3BiegmJauj0c1RCSoZ5beQ@mail.gmail.com> (raw)
In-Reply-To: <83sf79auwz.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4735 bytes --]

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@gnu.org> wrote:

> > From: Ambrose Kofi Laing <aklaing@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.
>

[-- Attachment #2: Type: text/html, Size: 5773 bytes --]

  reply	other threads:[~2023-09-20 17:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 17:59 bug#66111: is there a problem with --prefix? Ambrose Kofi Laing
2023-09-20 12:30 ` Eli Zaretskii
2023-09-20 17:04   ` Ambrose Kofi Laing [this message]
2023-09-30 23:29     ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD9Vp+69vS-B7YHwsq4ybc3krjJw3BiegmJauj0c1RCSoZ5beQ@mail.gmail.com \
    --to=aklaing@gmail.com \
    --cc=66111@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).