unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Alan Third <alan@idiocy.org>
Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org
Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS)
Date: Mon, 14 Jun 2021 22:19:50 +0300	[thread overview]
Message-ID: <835yyg5k4p.fsf@gnu.org> (raw)
In-Reply-To: <YMegxMZjur+HwO1M@idiocy.org> (message from Alan Third on Mon, 14 Jun 2021 19:32:36 +0100)

> Date: Mon, 14 Jun 2021 19:32:36 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org
> 
> > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44
> > 
> > Hmm... that problem was solved, though?  So how come it comes up once
> > again?
> 
> It was solved for the .app use case, perhaps that broke the Unix-style
> install case?

Could very well be, see below.

> I have to admit that I don't really understand this and have a very
> limited understanding of how the makefiles build the .app or not.

My primary worry is not the Makefiles, it's what the installed Emacs
does upon startup to find its requisite files.

> >   . the Emacs binary
> 
> Emacs.app/Contents/MacOS/Emacs
> 
> (This is different on GNUstep builds. I think it's
> Emacs.app/Contents/Emacs.)
> 
> >   . the .pdmp file
> 
> The same location as the binary. That was my change and it was done
> that way because I don't really understand any of this but that
> happened to work.

If the pdumper file is near the binary, I think Emacs will decide it's
running uninstalled, and will look for the *.eln files in
../native-lisp relative to where the binary lives.  Which is not
necessarily what you want, AFAIU.

> >   . the auxiliary executables (hexl, movemail)
> 
> I believe they're in Emacs.app/Contents/MacOS/libexec.
> 
> (Again, this is different on GNUstep.)
> 
> >   . the *.eln files
> 
> Emacs.app/Contents/Resources/native-elisp, or something. I'm not at a
> Mac to check right now, but definitely under Resources.

OK, please tell after you find out.

> > Also, I understand that the "normal" Unix-style install has the usual
> > tree hierarchy rooted at /usr or /usr/local, and there everything
> > "just works"?

You didn't answer this one.  Are we using the Unix-style hierarchy in
this case, i.e.:

  . Emacs binary in /usr/bin
  . the .pdmp file in /usr/libexec/emacs/VERSION/ARCHITECTURE
  . the *eln files in /usr/lib/emacs/VERSION/native-lisp

?

> > If so, when (at configure time, at installation time,
> > at some other time?) is the decision made whether the install will be
> > one or the other?
> 
> I believe there's a ./configure flag. But like I said before, for the
> other paths there's a run-time check, so I'm not sure how it all ties
> together.

Which run-time check did you have in mind?





  reply	other threads:[~2021-06-14 19:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-13  3:13 bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Matthew Bauer
2021-06-13  6:37 ` Eli Zaretskii
2021-06-13 16:37   ` Alan Third
2021-06-13 17:21     ` Eli Zaretskii
2021-06-13 19:30       ` Alan Third
2021-06-14 12:42         ` Eli Zaretskii
2021-06-14 18:32           ` Alan Third
2021-06-14 19:19             ` Eli Zaretskii [this message]
2021-06-16 18:25               ` Alan Third
2021-06-16 18:45                 ` Eli Zaretskii
2021-06-19 17:04                   ` Alan Third
2021-06-22  3:55                     ` Matthew Bauer
2021-06-22  8:32                       ` Alan Third
2021-06-22 16:51                         ` Matthew Bauer
2021-06-22 16:59                           ` Alan Third
2021-06-22 17:24                             ` Alan Third
2021-06-22 23:01                               ` Matthew Bauer
2021-06-23 15:59                                 ` Alan Third
2021-06-23 20:46                                   ` Matthew Bauer
2021-06-23 20:48                                     ` Alan Third
2021-06-26  9:38                                     ` Alan Third

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=835yyg5k4p.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=48994@debbugs.gnu.org \
    --cc=akrl@sdf.org \
    --cc=alan@idiocy.org \
    --cc=mjbauer95@gmail.com \
    /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).