[Top][All Lists]

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

Re: Files from gnulib

From: Paul Eggert
Subject: Re: Files from gnulib
Date: Tue, 25 Jan 2011 16:54:16 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101208 Thunderbird/3.1.7

On 01/25/11 13:54, Eli Zaretskii wrote:

>     This makes the entire unpacking procedure extremely
>     complicated and thus error-prone

I don't see why.  With GDB it's two commands:

  djtar -x -p -o gdb-7.2/djunpack.bat gdb-7.2.tar.gz > djunpack.bat
  djunpack gdb-7.2.tar.gz

Why would it be more complicated than that for Emacs?

>   . Once the remapping is maintained by humans, it becomes unreliable.

No, not if it's checked.  Surely the check can be automated reliably.

> the subdirectories of the Emacs tree will have to be hard-coded in
> config.bat, which is yet another source of errors, when a
> subdirectory is added or removed.  (The alternative, of using a port
> of GNU Find, would mean addition of another tool that is not
> required today for building Emacs.)

That should not be a problem.  'find' is already required to build
Emacs; for example, Makefile.in uses it.  It is easy to run 'find'
as part of the process that makes a distribution, and to put its
output into config.bat or the equivalent, so there is no need to run
'find' under MS-DOS.

> Perhaps it's possible to solve all this in a satisfactory manner, but
> doing so would require a lot of work,

I don't think it'd take much work to do the above.  I can write
scripts to do the check and to do the find, since they can all be done
on a standard GNU platform.  What else is needed?

On 01/25/11 14:06, Eli Zaretskii wrote:

> And what about the emacs-25.chg file?  Would you expect users to
> google for it as well, and copy-paste it into their shell window?

No, I would expect users to extract it from the tarball much as
is already done with GDB and djunpack.bat.  That's simple, and it
would work.

>> For example, it should be pretty easy to check emacs-25.chg
>> automatically; is that done with GDB?
> Yes, it is done.  But it doesn't catch all the errors.

How is that checking done, and what errors doesn't it catch?
I don't see the checking in the GDB 7.2 distribution.

> We are talking about renaming files in the Emacs repo.  Why would
> gnulib developers have any say in that?

Because we automatically sync files from gnulib into Emacs.
What I think you are suggesting, is that we rename gnulib files,
and edit their contents, after copying them from gnulib into Emacs.
But this will break the existing "make sync-from-gnulib", or require
"make sync-from-gnulib" to be considerably more complicated.

The renaming and copying is needed only on MS-DOS; it's not needed
for any other platform.  It makes sense to do it only on MS-DOS.
This will simplify maintenance on non-MS-DOS platforms; for example,
it will make it easier to propagate fixes from Emacs back to gnulib.

>> Also, the problem of non-8+3 file names does not seem to be limited
>> to gnulib-derived files.
> Yes, they are limited to gnulib-derived files.  If you mean Org, I'm
> sure those files will be renamed.

I meant all the other files that have 8+3 issues.  These are all
problems, even if the solutions differ for different cases.

> Who is "we" here, I wonder.

I can write the above scripts for Emacs.  The ideas can be propagated
into GDB later, as needed.

reply via email to

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