Proposed gnulib renames

[Eric Blake]

[intentionally breaking threading and retitling this, to try and make it
easier to see replies to just this aspect of the thread]

[well, my first attempt at breaking threading failed; apologies for the
duplicate, but here's a resend with identical contents to make good on
the promise of a new 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:
> >
> >  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=11206

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=11352

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=11234

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

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature