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

[Paul Eggert <eggert@cs.ucla.edu>]

On 2025-01-02 12:30, Eli Zaretskii wrote:

>> 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.

Oh, I meant only that module names are idiosyncratic, and some are 
substrings of others, and it's a bit of a pain to get the substitutions 
exactly right.

It could be done, but it's not worth the effort. As far as I can 
remember this is the first module renaming to affect Emacs since 
lib/gnulib.mk.in was introduced in 2017. Such a problem is in the noise 
compared, to ...


>> 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.

... this one.


> 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.

That's understandable, and I wasn't suggesting that we migrate all of 
Emacs's stuff into Gnulib. All I was thinking is that Emacs could use 
lib/config.mk.in unchanged, even when Emacs is being built on 
MS-Windows. (Admittedly this is not a project I could help much with.)