Re: Proposed gnulib renames

[Bruno Haible]

Hi Eric, Eli,

Remember that Eli said that the entire discussion is about renaming files
in the Emacs repository, not in gnulib [1]. I also pointed out that MSDOS
support is outside of gnulib's scope [2].

On this background, for me the goal is not to do any renamings in gnulib,
but rather to help the Emacs maintainers do these renamings easily when
they pull from gnulib.


1) About c++defs.h:

I have proposed in [2] a modification to the Emacs sources that will ensure
that
  - No c++defs.h is contained in the build.
  - A gnulib-local/modules/c++defs.orig file is contained in the tarball but
    not used in the build. According to Eli [3][4] the djtar program can
    deal with such a file automatically.


2) About *.in.h include files:

Eric Blake wrote:
> 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).

The simplest way to deal with this is that the script for updating the
Emacs sources from gnulib
  1. runs "gnulib-tool"
  2. looks at list of lib/*.in.h files,
  3. performs some 'mv' commands to rename them,
  4. performs some sed replacements on the generated Makefile.am.
Compared to the sed processing that is done by gnulib-tool, this is really
minor.

Eli Zaretskii says in [5]:

> I'm okay with renaming them to use underscores.  But if gnulib
> maintainers object, the djtar utility will take care of these, too.
> Editing Makefile.in to refer to them in config.h should not be a big
> issue.

I agree with Eli that a bit of hand-written renaming in the script
is feasible and maintainable.


3) About the collision of gnulib-cache.m4, gnulib-comp.m4, gnulib-common.m4:

Only one of these files is in gnulib. The other two are generated, and these
files are used by two programs: 'gnulib-tool' and 'aclocal'. For
'gnulib-tool', the file names matter, but 'gnulib-tool' is only invoked
from a specific script or Makefile in the Emacs sources. For 'aclocal',
the names of the .m4 files don't matter.

So, I would propose that you change the script from

   gnulib-tool ...<many options>

to

   if test -f m4/gl-cache.m4; then mv m4/gl-cache.m4 m4/gnulib-cache.m4; done
   if test -f m4/gl-comp.m4; then mv m4/gl-comp.m4 m4/gnulib-comp.m4; done
   gnulib-tool ...<many options>
   mv m4/gnulib-cache.m4 m4/gl-cache.m4
   mv m4/gnulib-comp.m4 m4/gl-comp.m4

Eric Blake wrote:
> 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).

It is out of question to rename things in a way that would affect all
gnulib users. If necessary, we could introduce a special option or two
in gnulib-tool, for Emacs developers to use. But even this is not needed,
given that it can be done with two 'mv' commands before and two 'mv'
commands after the invocation of gnulib-tool.


Eli, do these three proposals solve the issues? If not, what's remaining?

Bruno


[1] http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00865.html
[2] http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00779.html
[3] http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00827.html
[4] http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00866.html
[5] http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00922.html