Re: Proposed gnulib renames

[Eric Blake]

On 01/26/2011 08:58 AM, Eli Zaretskii wrote:
>> 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.
>
> And Bruno already voiced his objections, so I guess I will have to
> live will that.  It's not a big deal to edit with Sed the few files
> that refer to c++defs.h, as part of the config.bat run.  Of course, if
> Bruno will change his mind, it will be even better.

Ah - http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00323.html

But Bruno's suggestion of using gnulib-tool --local-dir for the
emacs-only rename for c++defs might make sense; this module is less
volatile than the *.in.h issue, and so is less likely to cause perpetual
merge grief in maintaining such a patch.

>
>> 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
>
> I'm okay with renaming them to use underscores.  But if gnulib
> maintainers object, the djtar utility will take care of these, too.

The whole point is that they used to be underscore, but we switched as
part of a process of preferring dash over underscore.  If we do the
rename in gnulib, I'd prefer it to be to a dash.

> Editing Makefile.in to refer to them in config.h should not be a big
> issue.

Good to hear - if the tar file automatically flattens them into a
particular name, and your script can touch up the Makefile.in to refer
to that flattened name, then we've isolated the problem outside of gnulib.

>> 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).
>
> Of course, it is enough to rename only 2 of the 3, to avoid file-name
> clashes.  So if your suggestion to rename gnulib-common.m4 and
> gnulib-comp.m4 is accepted, that would solve the problem entirely.

Bruno has not yet weighed in on this proposal (his earlier objection was
just to the c++defs naming).

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

signature.asc
Description: OpenPGP digital signature