Re: [feature/native-comp] breakage on build

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Phillip Lord <phillip.lord@russet.org.uk>
>> Cc: akrl@sdf.org,  emacs-devel@gnu.org
>> Date: Sat, 06 Feb 2021 12:58:59 +0000
>> 
> Could it be that Emacs when started from the mingw64 shell picks up
> GCC components from this PATH, and thus GCC will then look for the
> libraries and object files for native-comp in the "normal" mingw64
> installation, not in the Emacs tree you created?  In that case the
> fact that native-comp works from the mingw64 shell is not interesting,
> as ll it says that your duplicate GCC installation is somehow
> incomplete.
>
> I don't see any other variable that I think could be related.  (But I
> don't use MinGW64, so I could miss something.)  However, you show the
> exported variables from the MSYS Bash, whereas what we need to look at
> is the environment variables as seen by GCC, when it is run from
> Emacs.  The value of process-environment in both cases should be a
> good first step.


Eli, Oscar, Andrea

Apologies, I had forgotten that I had moved machines during testing. It
was simply the path (and exec-path) that was missing. My own time is
mine to waste, but apologies for wasting yours.

I am coming to the conclusion that I am going the wrong path here. I
think supporting native-comp and keeping a sanely sized Emacs
distribution are not compatible objectives. I do not want to return to
the Emacs-26 distribution, which included a lot of msys2.

I think that the base distribution of Emacs-28 should not include
JIT native-comp. If people want this, they should get it through the
msys2 co-installation that Oscar and I have been talking of.

However, we could just do a full AOT native-comp, so at least the
Emacs-28 packages would all benefit. Andrea, can the native-comp branch
still load *eln files even if it can't produce them?

Phil