GNU bug report logs - #46256
[feature/native-comp] AOT eln files ignored if run from build tree

Previous Next

Full log

Message #211 received at 46256 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46256 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#46256: [feature/native-comp] AOT eln files ignored if run
 from build tree
Date: Fri, 5 Mar 2021 15:18:12 +0000

On Fri, Mar 5, 2021 at 2:55 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Andrea Corallo <akrl <at> sdf.org>
> > Cc: 46256 <at> debbugs.gnu.org
> > Date: Fri, 05 Mar 2021 13:56:24 +0000
> >
> > > Why can't we have a rule in the Makefile conditioned by
> > > HAVE_NATIVE_COMP?
> >
> > We certainly can, the difficult part is to generate the rule as the .eln
> > filename is known only by the Emacs binary.  I'm probably missing
> > something.
>
> Oh, you mean because of the ABI hash?  Yes, that'd preclude using Make
> to decide when a .eln file needs to be regenerated.

I think storing the ABI hash somewhere accessible in the build tree is
a good idea, anyway, and then we could do it with some make magic.

> > [ To be considered also that as of today libgccjit is not meant to work
> > for cross compilation. ]
>
> Then perhaps we could invoke Emacs only in order to detect when the
> ABI has changed.

IIUC, the ABI only changes when DEFUNs do, and then we regenerate most
of the Emacs binaries anyway, so we could make abi-hash depend on
gl-stamp/globals.h?

> Because when that happens, we need to regenerate all
> the preloaded *.eln files anyway, so there's no need to test
> individual files.  Right?

But do we want to keep the old files around in case the ABI changes
back? I don't think we do.

Pip

Previous Next

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