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

[Phillip Lord]

Óscar Fuentes <ofv@wanadoo.es> writes:
>> This arrangement evidently works for you, but it doesn't mean it is
>> the best one.  For example, AFAIU it generally doesn't allow invoking
>> the commands outside of Emacs.  I don't think it's a good idea to have
>> all those useful programs ghettoized to work only from Emacs, because
>> Emacs is just one tool in the user's tool-chest.
>
> IIUC one of the problems Phillip has is to include certain tools on the
> Emacs distribution (either on the binary package he uploads or on
> auxiliary ones that can be installed on request, i.e. MSYS2/MinGW-w64)
> on such a way that Things Work (TM). Setting exec-path would solve this.
>
> Furthermore, if the MSYS2/MinGW-w64 way of providing tools ends winning,
> Phillip could just simply build an MSYS2 package which current MSYS2
> users would download and install while non-MSYS2 users would download an
> "installer" that installs MSYS2/MinGW-w64 (from their servers) and then
> the Emacs MSYS2 package on top. This has the advantage that all
> dependencies can be listed on the package and `pacman' (MSYS2 package
> manager) will install them automatically. With this and the mentioned
> modification to exec-path, everything works, no PATH meddling required.
>
> Sure enough, there are people that prefer the traditional tarball with
> just Emacs binaries, but IMHO it is fair to say that those users must
> deal with the dependencies themselves.


I have made life more complicated, I am afraid, by doing two things at
once. There are three issues here which are related but different.

First is Emacs with associated DLLs. I have just moved this to using
ntldd to work out the dependent DLLs. That seems to be working fine, and
seems better to me that what we had with Emacs-26 which is half of an
msys2 install stuff inside a zip file called "Emacs".

Second, is native-comp. It appears that, as well as the DLLs, libgccjit
also needs some tools locally (as, ld at least). I don't know what those
all are yet, and that is going to need some working out. When I have we
need a way of making them available so that Emacs can run.

The third is how I can make a more tooled up Emacs with associated
tooling. My package of Emacs once installed cannot check spelling which
seems pretty poor for a text editor. Nor interact with a git repo which
is pretty poor for a code editor.

It's attractive in the first instance to conflate these three. We could
install all the dependencies for Emacs and all the tools we want using
pacman. But, I think this is wrong, because Emacs itself
(i.e. emacs.exe) is a fixed point in time; it needs to have a fixed set
of dependencies and they should not update for a given emacs.exe. This
fits poorly with the msys2 rolling release. So, problem one requires us
to extract dependencies from a given release of msys2 then freeze them.
I expect problem two will be the same, but I haven't fixed that yet.

Problem three is different. I think here the solution is to install
msys2 inside the Emacs installation, then fiddle with things so that
Emacs uses it. If this works correctly, then an Emacs installation will
also include and use aspell or hunspell and git. And if we want more
packages, we could run pacman and install anything we chose. It would
even be possible to update things like libjpeg (as a trivial example)
inside this msys without having any impact on Emacs because it would use
the fixed libjpeg that it was installed with. There are undoubtedly lots
of details to worry about here, but I think I know at least how to do
the install process now.

At the moment, number one is working, number two I think needs to be
solved as lots of people will want native comp on windows, and number
three is (and may remain) aspirational.

Phil