Re: master bdb13a0e5c5 1/2: Adjust to Gnulib’s recent module renaming

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 2 Jan 2025 11:38:34 -0800
> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2025-01-02 09:57, Stefan Kangas wrote:
> > I'd find a "warning: new modules added, notify emacs-devel for
> > possible w32 adaption" message more useful than something that blindly
> > pipes things to mail(1).
> 
> Thanks for the suggestion; I installed the attached.

Thanks, this is an improvement.

> I don't see a nontrivial way to update nt/gnulib-cfg.mk automatically, 
> even just for module renames as Eli suggested, as there are too many 
> possibilities for screwups.

Can you elaborate on that?  I only meant to edit the
OMIT_GNULIB_MODULE_* settings when a module gets renamed, nothing
else.  That is, if module FOO is renamed to FOO_BAR, the
OMIT_GNULIB_MODULE_FOO should be edited to OMIT_GNULIB_MODULE_FOO_BAR.

> The "right" way to fix this would be to adjust Emacs and Gnulib so that 
> builds would work the same way on MS-Windows that they do everywhere 
> else (i.e., nt/gnulib-cfg.mk would become unnecessary). However, as I 
> understand it this would be nontrivial and anyway it would require 
> MS-Windows expertise that I lack.

The problem here is that we omit modules because Emacs on Windows
implements or emulates many functionalities in a way that is specific
to Emacs and might not work well elsewhere.  One notable example is
that Emacs supports UTF-8 encoded file names, something Gnulib on
Windows does not, so we cannot use any Gnulib modules that handle file
names.  Gnulib is a general-purpose library, so it cannot use some of
the enhanced functionality we use in Emacs because we have intimate
knowledge of what Emacs needs and which functionalities it actually
uses.  For example, the emulation of pselect is tightly coupled to
what Emacs uses it for.

> In the meantime, module renames are rare enough that doing things by 
> hand should take less work overall. Besides, the main problem here is 
> changes to modules and/or adding modules, which I don't think 
> admin/merge-gnulib can handle by itself.

Yes, all the other changes cannot be automated.  But I thought at
least renames can be.