bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Files from gnulib


From: Eli Zaretskii
Subject: Re: Files from gnulib
Date: Wed, 26 Jan 2011 01:01:42 -0500

> Date: Wed, 26 Jan 2011 06:12:55 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
>       address@hidden
> 
> > I'd like to pursue the idea of renaming the files only
> > on the MS-DOS platform.  This approach shouldn't take
> > that much work now, and it should save time in the future
> 
> That approach as suggested (modeled on what GDB does) is unacceptable,
> sorry.

Here's a compromise that at least I can live with; hope others can,
too:

 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.

 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.

As long as the list of files that get handled by 1) is relatively
small and kept under control, this is manageable.  This means no "open
season" for disregarding the issue altogether, as in "we already have
such problems elsewhere, why not add a few more".

I hope that as long as the list of files that are handled by 2) is
short (3 for now), that would be regarded as manageable and acceptable
by gnulib people.

[Make no mistake: supporting 1) is still a complication.  There's more
there than meets the eye.  For example, when djtar runs on Windows, it
doesn't perform any automatic renames, because it knows that long file
names are available (DJGPP has built-in support for them in the
Standard C library).  So, to support the Emacs build on both plain DOS
and Windows, config.bat will need to do slightly different things in
each case, which means more scripting and more testing.  But these
complications are relatively minor, don't affect the end users, and I
have good experience with solving such problems, in Emacs and
elsewhere.]



reply via email to

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