help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Emacs 26.1 on Windows is HUGE


From: Phillip Lord
Subject: Re: Emacs 26.1 on Windows is HUGE
Date: Sat, 27 Apr 2019 12:17:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

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

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>>> Maybe report that to the MSYS2 packagers.  It's IMO wrong to consider
>>> every package that comes with a few Python script not essential to its
>>> functionality to be dependent on Python.
>>
>> Hmmm. Actually, it's indirect, via libglib2.
>>
>> The dependency was added deliberately in this commit.
>>
>> d394f202ab275d931f9408c68a4dc1fa95ad723c
>>
>> viewable here:
>>
>> https://github.com/msys2/MINGW-packages/commit/d394f202ab275d931f9408c68a4dc1fa95ad723c#diff-4edc48d8f1e38f841d1aa74999389b6e
>>
>> A priori, I am a bit surprised this is a runtime rather than build time
>> dependency, or possibly the dependency on python should be in
>> gobject-introspection only. Adding a python dependency to glib seems
>> quite a blunt solution. But my knowledge in this is limited to say the
>> least. What do think, Eli? Worth reporting?
>
> On that URL an user asked about the dependency on python, no response.
>
> MSYS2 is strongly influenced by Archlinux. Although MSYS2 is quite
> sloppy about dependencies (among other things) Archlinux is a differente
> beast, and on its PKGBUILD (1) for glib2 python is listed on
> `makedepends' and `optdepends', not on `depends'. For me, that warrants
> a report. Better, create a PR moving python to `makedepends' and
> `optdepends' and CC the author of the commit you referred to on the PR
> message.

Well, we shall see -- I have put in a comment.


> But... don't expect that MSYS2 makes changes to adapt to your specific
> needs. Creating an stand-alone distribution of Emacs is not the same as
> managing packages in MSYS2. For instance: as you know, lib* packages in
> MSYS2 comes with binaries + development files (.a & *.h ...) while
> distributing those with Emacs is dubious. You already remove them from
> your zipfiles, why don't do the same with python?

No, I don't. I put in all the files that are declared as part of the
dependency package.

I could detect and remove specific dependencies, or with a bit more
work, remove a part of the dependency tree. But I rather not go down the
path of maintaining a metadata list for msys2 independtly.

> BTW, since MSYS2 is sloppy with dependencies, you can't rely on them
> for making sure that everything is included.

So far, I have had no bug reports about this, just the opposite -- that
too much is included. And some requests to add other things. I'm just
not convinced that effectively producing a seperate minimal MSYS2
distribution is where I want to go. For people who want a lot more or
less, installing msys2 independently and then droppping the no-deps
package on top seems the way to go.


> And on different topic, did you test that C-h i works as it should? Does
> it show the Emacs info files? There is a long-standing problem with
> Emacs on MSYS2 about this, although IIRC only happens when you install
> Emacs as an MSYS2 package. But since testing it only takes a few
> seconds... (I can't test myself, computer attracted lightning)

Hmmm. Sort of. If you click runemacs.exe from the windows explorer it
works. If you launch it from a mingw64 shell, no, it doesn't. Or rather
it works, but you get the msys info which doesn't link to Emacs.

I am rather dependent here on people filling bugs; I don't actually use
Emacs on windows, just build it.

Phil




reply via email to

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