[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed gnulib renames
From: |
Paul Eggert |
Subject: |
Re: Proposed gnulib renames |
Date: |
Wed, 26 Jan 2011 16:39:43 -0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 |
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.
Re: Proposed gnulib renames, Eric Blake, 2011/01/26