Re: [Emacs-diffs] master 5d4c539: Add lcms2 interface

Re: [Emacs-diffs] master 5d4c539: Add lcms2 interface

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Wed, 13 Sep 2017 11:46:46 -0400
> Cc: Mark Oteiza <mvoteiza@udel.edu>
> 
> >     configure.ac: Add boilerplate for configuring and detecting liblcms2.
> 
> Can't this be a module?

Only if we don't want this functionality in Emacs where the library is
available.

> The whole point of the addition of the module interface was so that we
> don't end up with the situation where installing Emacs either requires
> a zillion libraries that are "hard-coded" (tho dynamically linked) into
> the binary, or it only requires a few libraries but then the other
> features can't be used.

To me, modules are for users to extend Emacs, not for us to add
functionality.  It makes very little sense to have anything that is in
core via modules.  I see only disadvantages there: the code is much
less readable, and has more limitations on what it can do.

Re: [Emacs-diffs] master 5d4c539: Add lcms2 interface

[Stefan Monnier]

>> >     configure.ac: Add boilerplate for configuring and detecting liblcms2.
>> Can't this be a module?
> Only if we don't want this functionality in Emacs where the library is
> available.

Hmm... indeed I now see that liblcms2 is already linked into Emacs if we
use the Gtk GUI.  It's not linked if you use the Lucid GUI, OTOH.

> To me, modules are for users to extend Emacs, not for us to add
> functionality.

That's one of the benefits.  The other is that you don't need to choose
at compile-time which libraries will be (and have to be) available at
run-time.

In Windows, we already do dynamic-loading of libraries such as gnutls,
so the issue is less serious, but in GNU/Linux it's always a hassle.

> It makes very little sense to have anything that is in
> core via modules.  I see only disadvantages there: the code is much
> less readable, and has more limitations on what it can do.

That calls for improving the module system, not circumventing it.


        Stefan

Re: [Emacs-diffs] master 5d4c539: Add lcms2 interface

[Paul Eggert]

Stefan Monnier wrote:
> Hmm... indeed I now see that liblcms2 is already linked into Emacs if we
> use the Gtk GUI.  It's not linked if you use the Lucid GUI, OTOH.

Would it address your concerns if we enabled lcms2 only when Gtk is already in use?

Re: [Emacs-diffs] master 5d4c539: Add lcms2 interface

[Stefan Monnier]

>> Hmm... indeed I now see that liblcms2 is already linked into Emacs if we
>> use the Gtk GUI.  It's not linked if you use the Lucid GUI, OTOH.
> Would it address your concerns if we enabled lcms2 only when Gtk is
> already in use?

No, my comment was more general than specifically aimed at lmcs2.


        Stefan

Re: [Emacs-diffs] master 5d4c539: Add lcms2 interface

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org, mvoteiza@udel.edu
> Date: Wed, 13 Sep 2017 12:23:34 -0400
> 
> > To me, modules are for users to extend Emacs, not for us to add
> > functionality.
> 
> That's one of the benefits.  The other is that you don't need to choose
> at compile-time which libraries will be (and have to be) available at
> run-time.
> 
> In Windows, we already do dynamic-loading of libraries such as gnutls,
> so the issue is less serious, but in GNU/Linux it's always a hassle.

I think we should indeed welcome patches to migrate to a similar
dynamic-loading scheme on Posix hosts.  Most of the code can be simply
lifted from the Windows port, with minimal changes.

> > It makes very little sense to have anything that is in
> > core via modules.  I see only disadvantages there: the code is much
> > less readable, and has more limitations on what it can do.
> 
> That calls for improving the module system, not circumventing it.

That would be welcome as well, but the issues were identified long
ago, and no one volunteered to work on that until now.  Moreover, I
understand some of us actually think it would be wrong to go that way.