> Date: Wed, 26 Jan 2011 08:19:13 -0700 > From: Eric Blake <ebl...@redhat.com> > CC: c...@stupidchicken.com, egg...@cs.ucla.edu, bug-gnulib@gnu.org, > monn...@iro.umontreal.ca, emacs-de...@gnu.org, > Bruno Haible <br...@clisp.org> > > > 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.
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. > 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. Editing Makefile.in to refer to them in config.h should not be a big issue. > 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): Life has its surprises. I found some free time to work on support for bidirectional editing in Emacs, and as a side effect, I could invest some of that time into reviving the DOS build. > > 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). 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. Thanks!
