emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Phillip Lord
Subject: Re: [feature/native-comp] breakage on build
Date: Sun, 07 Feb 2021 18:56:04 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>> Well I agree. But "fat beast" is an understatement. If I install msys2,
>> Emacs and all the dependencies, it comes in at nearly 2Gb on disk. The
>> install takes around half an hour on my machine (and only that fast
>> because I turn of the Windows antimalware service).
>
> The dominating factor on my experience is the download time. Telling
> pacman to use the right mirror solves this. (See
> /etc/pacman.d/mirrorlist.* )

I am running it in an under powered VM, which probably explains the
difference.


>> It also includes a
>> pile of stuff that the user might not want (i.e. python or ruby) because
>> they have their own installation already.
>
> There are some serious python buffs among the MSYS2 maintainers and it
> is listed as a dependency of anything that could remotely use it, but
> ruby is not in my installs (searched for ruby.*) and they certainly
> contain much more than Emacs needs, although I don't install all
> optional dependencies.
>
> Maybe your dependency list would benefit from some review. Just show it.

I just said "ruby" as it appeared in the corner of my eye.

The full dependency list is this:

mingw-w64-x86_64-giflib
mingw-w64-x86_64-gnutls
mingw-w64-x86_64-harfbuzz
mingw-w64-x86_64-jansson
mingw-w64-x86_64-lcms2
mingw-w64-x86_64-libjpeg-turbo
mingw-w64-x86_64-libpng
mingw-w64-x86_64-librsvg
mingw-w64-x86_64-libtiff
mingw-w64-x86_64-libxml2
mingw-w64-x86_64-xpm-nox

I notice that it's missing gmp which I think it should have although
it's gets it transitively. On native-comp this also needs:

mingw-w64-x86_64-libgccjit


>> But, you are correct, a value add with all the tools installation of
>> Emacs might as well just be an msys2 install running. I believe you
>> already have already done that work! Or a powershell script that pulls
>> down msys2 installs it and dependencies and then pulls down
>> Emacs-no-deps over the top might be the way to go.
>
> I have a trivial bash script that installs several packages. I use it
> after a fresh MSYS2 install and then I'm ready to go. Downloading MSYS2,
> installing it, running the script... it all takes about 30 seconds of
> attended work. It's that simple.

Yes. I think that is a good way to go; I was looking at something
similar, except it would install msys2 as well over the top of an Emacs
install. And then update the msys2 install to be useful.


>>>> 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.
>>>
>>> The goal you are pursuing is difficult enough and, IMHO, you are
>>> complicating it further by adding (somewhat fuzzy) requirements that lie
>>> beyond the point that seems reasonable to me, speaking as an Emacs user.
>>
>>
>> Maybe. What I see is people using Emacs and getting their spelling wrong
>> because there is no spell checker.
>
> This Emacs has an spell checker and I get spelling wrong, as well as
> grammar and everything else :-)
>
> The route of creating an MSYS2 binary package (well, two, if you wish to
> support i686) is as easy as it gets: create the package (I can help you
> with it if the current PKGBUILD for mingw-w64-emacs-git in
> https://github.com/msys2/MINGW-packages-dev/tree/master/mingw-w64-emacs-git
> needs work). Then instruct the users to install MSYS2, download your
> binary package and install it with pacman (copy and paste a command on
> the MSYS2 shell). The most difficult step is to create a desktop icon
> for runemacs.exe, which can be manually accomplished on the usual way
> (and we used to have a tool for that, IIRC). That's about two minutes of
> attended work.


I was thinking of doing it the other way up. We install Emacs as now
(either unzipping or using the installer). Then, Emacs runs, detects the
first run and says "do you want to install msys2 also". If it does, then
away we go, otherwise, we leave as is -- an editor rather than a pilot
of multiple tools.

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.


> At that point, you solved the dependencies problem, the source code
> availability problem (for the dependencies) and delegated lots of
> maintenance work.
>
> But we need /mingw64/bin (its native equivalent, actually) on exec-path
> for the .exe dependencies to work. We can tell the users to modify their
> .emacs.el, but it would be much nicer if Emacs did that itself.

I would agree. This would also mean we could point Emacs as an existing
msys2 installation. Or install Emacs in one place and msys2 in another.


> Oh, and we still miss some dependencies, like `find'. But that can be
> added too, once we (the MSYS2 contributors) check that it will not break
> other things.
>
> Oh-2, currently MSYS2's Emacs does not install some things (e/ctags,
> IIRC) because there are better alternatives on the repository.

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.

Are you interested in helping with something along these lines? I have
only so much time to give to Emacs and it will take me sometime to get
any of this done. If so, we can write up a slightly more detailed plan.

Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]