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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
