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 --]
next prev parent 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).