[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed gnulib renames
From: |
Eric Blake |
Subject: |
Re: Proposed gnulib renames |
Date: |
Wed, 26 Jan 2011 09:08:06 -0700 |
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 |
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