On 01/26/11 08:36, Jim Meyering wrote: > Renaming files like those to avoid the 8.3 collisions does not seem > like the right move, especially since we (at least I) have no idea of > the size of the user base we would be accommodating.
I agree that wholesale renaming is not a realistic option. It appears that Eli has a solution for c++defs and there's no need to worry about it right now. The *.in.h problem is more serious, though, as it limits include file names to 7 letters before the dot. For example, in DOS, the name "fnmatch-in.h" is equivalent to "fnmatch.h" (the excess chars "-in" are ignored by the file system), so one cannot have a Make rule that creates the latter from the former. Currently this is not a problem since all the .in.h files that Emacs uses are 7 characters or less. But this is not a tenable restriction in the long run. One thing does strike me, though, as being a useful thing we can do regardless of the DOS business. Currently we build lib/c++defs.h from build-aux/c++defs.h as part of ordinary 'make'. But lib/c++defs.h is the same on all platforms. It would save work for ordinary 'make' if we distributed lib/c++defs.h, so that the maintainer can build it rather than the builder. Similarly for lib/warn-on-use.h and lib/arg-nonnull.h. I can propose gnulib changes along those lines, unless there's some objection. I don't expect this to affect the difficulty of the Emacs MS-DOS build.
