From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Blake Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Proposed gnulib renames [was: Files from gnulib] Date: Wed, 26 Jan 2011 08:19:13 -0700 Organization: Red Hat Message-ID: <4D403B71.2010509@redhat.com> References: <83y66bzuhc.fsf@gnu.org> <4D3C81A1.70009@cs.ucla.edu> <83ipxfymox.fsf@gnu.org> <4D3E0A8E.1030400@cs.ucla.edu> <8362tdzl7m.fsf@gnu.org> <4D3E8E4C.1010000@cs.ucla.edu> <4D3F1171.5010201@cs.ucla.edu> <83y668yfgt.fsf@gnu.org> <83lj28y7h4.fsf@gnu.org> <4D3F7358.8000405@cs.ucla.edu> <83bp34xpyw.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5D52C4A5E3160E030171709B" X-Trace: dough.gmane.org 1296056604 10523 80.91.229.12 (26 Jan 2011 15:43:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 26 Jan 2011 15:43:24 +0000 (UTC) Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, Bruno Haible To: Eli Zaretskii Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Wed Jan 26 16:43:18 2011 Return-path: Envelope-to: gnu-bug-gnulib@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pi7Wf-000199-Vb for gnu-bug-gnulib@m.gmane.org; Wed, 26 Jan 2011 16:43:18 +0100 Original-Received: from localhost ([127.0.0.1]:49970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi7Wf-0003Ig-Al for gnu-bug-gnulib@m.gmane.org; Wed, 26 Jan 2011 10:43:17 -0500 Original-Received: from [140.186.70.92] (port=46886 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi7CV-0003Nc-W6 for bug-gnulib@gnu.org; Wed, 26 Jan 2011 10:23:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pi7BD-0003rk-6e for bug-gnulib@gnu.org; Wed, 26 Jan 2011 10:22:25 -0500 Original-Received: from mx1.redhat.com ([209.132.183.28]:16486) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pi79W-00039h-Df; Wed, 26 Jan 2011 10:19:22 -0500 Original-Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0QFJFkn026263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jan 2011 10:19:16 -0500 Original-Received: from [10.3.113.146] (ovpn-113-146.phx2.redhat.com [10.3.113.146]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p0QFJDBw003095; Wed, 26 Jan 2011 10:19:14 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7 In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.lib.gnulib.bugs:24981 gmane.emacs.devel:135022 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D52C4A5E3160E030171709B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [intentionally breaking threading and retitling this, to try and make it easier to see replies to just this aspect of the thread] On 01/25/2011 11:01 PM, Eli Zaretskii wrote: > Here's a compromise that at least I can live with; hope others can, > too: >=20 > 1) For c++defs.h and the lib/*.in.h files: rely on the automatic > renaming by djtar. Files that reference those will be edited by > config.bat as part of configuring Emacs for the MS-DOS build. Paul already suggested renaming c++defs.h to cxxdefs.h in gnulib, which makes sense to me in light of POSIX restrictions on portable filenames; however, this module belongs to Bruno, so it is his call. As for the *.in.h files, the ONLY other files that refer to those at build time are the Makefile snippets in module files that convert them over to *.h replacement headers. Here's a link to some of the back-discussion where we first settled on the name *.in.h in the first place in Oct 2007 (we were previously using *_.h, but underscores are painful to type in daily use; and also on the table at the time was the rejected idea of *.h.in and *.hin): http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11185/focus=3D11206 and given that the renaming from *_.h -> *.in.h was practically mechanical, a conversion from *.in.h -> *-in.h would likewise be mechanical, but I'm not sure whether to make that jump yet: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11182/focus=3D11352 that thread also included a quote from Eli, predicting the death of an emacs DOS build (for good or for bad, that prediction has not come true):= http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11182/focus=3D11234 >=20 > 2) For the 3 m4/gnulib-*.m4 files: rename them. I suggested one way > of renaming, but there's nothing sacred about that; any renaming > that will get rid of the name clash is fine with me. This would involve a change mainly to gnulib-tool (2 of the 3 gnulib-c* files are generated; there's also gnulib-tool.m4 to avoid clashing with). Changing gnulib-cache.m4 would have downstream effects on all gnulib clients; it could be done with a NEWS entry, but I'd rather avoid that. But the other two files (gnulib-common.m4 and gnulib-comp.m4) seem like fair game; how about the names gnulib-prereq.m4 (since all the common code is prerequisite to the rest of gnulib) and gnulib-list.m4 (since comp contains the computed list of files/macros installed by gnulib-tool). > As long as the list of files that get handled by 1) is relatively > small and kept under control, this is manageable. Right now, there is the c++defs naming issue (with user-visible changes to all gnulib clients, but worth making). Also, there are currently 63 *.in.h files available in gnulib (I'm not sure how many will ever be used by emacs), but I'd rather see the same change made to all 63 files (and their corresponding modules) at once if the change is made upstream in gnulib. I agree that use of gnulib-tool --local-dir won't quite work; it could easily patch the module descriptions (and makefile snippets) to refer to *-in.h files with minimal risk of too many upstream changes to track, but the rename itself is not possible via simple patch(1) files (yes, GNU patchutils is adding support for git-style rename patches, which would be much easier to maintain, but I don't know if we should rely on that yet). But if gnulib makes no change to these 63 files, then that's an upper bound on the possible complexity of Eli hand-maintaining the rename within the DOS build of emacs. > I hope that as long as the list of files that are handled by 2) is > short (3 for now), that would be regarded as manageable and acceptable > by gnulib people. It seems reasonable to me, but I'm not the primary author of gnulib-tool. Bruno? --=20 Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org --------------enig5D52C4A5E3160E030171709B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNQDtxAAoJEKeha0olJ0NqQPkH/A6FS0QWkfqZu7LGu5qOPxBE zCanf6+Tev4iNKD6UtrO1vY2osWftJ+A3m1jm5C3bskCW4ynrMFb3syPnOmsnL2S qpP/MJgrr7sHEWZK2z0pUYNkiB9lF+F4YWF/GFiErElVKBUCsHSSf6w6K2vabR5l l60dSQoNOpSYWDoVyIuQNiTIdnmZMHZKMW0Kjm1cqxH+nikOTAUt5CgwlFc7ShP+ fAV8VQFjpbCsz0EcJfFbV5IwcuidgIbcYb5TBHKfTzVe6/sx4Yc+bZxCVGWHjqFS z58Ibq2lWX+IZIU+ZEhnmHXV5K6bAMQGzvKpiTKrZ8hAUd5HJbmICaZPGIPqKdA= =mmpF -----END PGP SIGNATURE----- --------------enig5D52C4A5E3160E030171709B--