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

[Phillip Lord]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>>>> My original though was to bundle this into the install, but having done
>>>> a little bit of picking, I think a better solution would be to have the
>>>> first run of Emacs install a package from ELPA, which would actually do
>>>> the msys install.
>>>
>>> This is easier said than done :-)
>>
>> Why? I think the code for an unattended install is actually in the
>> .github actions for msys2.
>
> The hard part is not to install MSYS2, is to manage the install action
> from Emacs. Ask the user, remember his decision, provide a mechanism in
> case he changes his mind, detect and use existing installs, decide where
> to install... and more.


This is a little tricky, mostly because msys2 does some stuff when it
installs -- there is the "update and force close the terminal".

I was thinking of something along the lines of:

 - Do you want to use msys2 to provide additional tools
   - Do you want Emacs to install for you, or do you have an
      existing...
      - if install: where, or internal?
      - if existing: where is it
   - Do you want to install some standard packages that Emacs uses



>> An alternative would be to just stick a bash script onto the FTP site,
>> and tell people "install msys2 then run this". This is not such a bad
>> option.
>
> That's along the lines of what I described on a previous message,
> although I went to the extreme of suggesting to provide Emacs as a
> pacman package.

Yes. In this case, we'd have two ways of getting an Emacs. One which is
the current version -- a compiled Emacs with a few extra DLLS, and one
inside msys2 as a normal pacman package. It would mean that the two
packages would be built separately.


> Do you know that a pacman package contains a functional install? That
> means that once you have the MSYS2 binary package, by simply
> uncompressing it, adding the required dlls to mingw64/bin and zipping
> the contents of the mingw64 directory, you have your .zip distribution.

I hadn't thought of going that route, but it's an interesting idea.


>>>> And some critical things, like git which is not available as a mingw64
>>>> package; I have knocked together an mingw package for it; I have no idea
>>>> whether the msys2 maintainers would be interested in it.
>>>
>>> Do you have a PKGBUILD? Send me a copy and I'll look at it.
>>
>> https://github.com/phillord/MINGW-packages/tree/feature/mingw64-git/mingw-w64-git
>
> That lacks SSL/SSH and Perl dependencies for the commands that still
> depend on it.
>
> After looking at
>
> https://github.com/msys2/MSYS2-packages/blob/master/git/PKGBUILD
>
> I was expecting a more complex procedure.

Me too. The msys version is patched, I notice.

I also don't know whether there is a reason that msys2 doesn't already
have a mingw64 package for git. Maybe just because it doesn't, or
because people use gitforwindows, or because the simple approach taken
in my branch is hopelessly broken.


> If something as simple as this works, great. Otherwise, another
> possibility is to install MSYS2 git (the POSIX package) and tell the
> users to set vc-git-program / magit-git-executable, suppossing that it
> works. It is slower than the native port, though.

Yes. I think Eli is worried about the "supposing it works" bit.

Phil