From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master bdb13a0e5c5 1/2: Adjust to =?utf-8?Q?Gnulib=E2=80=99s?= recent module renaming Date: Thu, 02 Jan 2025 22:30:53 +0200 Message-ID: <86ldvthsaq.fsf@gnu.org> References: <86a5c9jf88.fsf@gnu.org> <6414b78b-ff06-4d51-9bc4-b36799343fe1@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11561"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 02 21:31:53 2025 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tTRrE-0002qo-2i for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Jan 2025 21:31:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTRqR-00030Z-VS; Thu, 02 Jan 2025 15:31:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTRqN-000304-Vf for emacs-devel@gnu.org; Thu, 02 Jan 2025 15:31:01 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTRqM-0003wj-2f; Thu, 02 Jan 2025 15:30:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=11w64oohBdzAnjiC8jlncPjG3593p9bhgSyHgZlzu4w=; b=EXVHHQtkDMPb0n4sxfkH ODLos/4zTPbMG4bZ8NBOYeYFdWfIv9BLb20f/vXMQu7b5bPhaSWj/pcNqzcXwdP5msghIGS0NtwxH kZcZyPuwFxQMt5JBYt3BK495HI63NBMQFF/gSr83KDuCmE0vFJKHPBnb7GgGKQbXmxtI3/0jaikfZ GETSsx+KlItZqZDvNrbxBpycM4BqfN53edJksGu6ZJ0GRvEHko7tCE1rdwcXW0weqco+dncvyUukz wWMlW2hh/39dcXaxFZ/U3WOHxXpxmQzx/IZm1rdDOunzusDnFy8Ao3moe2BSi3ufD5NCzltI87sHw zWXp4pR8pGaOnw==; In-Reply-To: <6414b78b-ff06-4d51-9bc4-b36799343fe1@cs.ucla.edu> (message from Paul Eggert on Thu, 2 Jan 2025 11:38:34 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327595 Archived-At: > Date: Thu, 2 Jan 2025 11:38:34 -0800 > Cc: emacs-devel@gnu.org > From: Paul Eggert > > 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.