bug-gnulib
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]