Re: Files from gnulib

[Paul Eggert <eggert@cs.ucla.edu>]

On 01/25/2011 08:10 PM, Eli Zaretskii wrote:

> It's done by the ARI script.  All I know about the errors is that some
> files still clash.

I looked into that, and the ARI script itself
<http://sourceware.org/gdb/current/ari/gdb_ari.sh> doesn't know
anything about 8+3 file names, so some other program must be doing it.
My guess is that they're using GNU doschk
<http://www.gnu.org/software/doschk/> and filtering the output.

If I run "make dist" on the Emacs trunk, and then ask GNU doschk
to report all 8+3 file name clashes in the resulting distribution, it
reports the following:

   ORG-COMP.EL    : ./lisp/org/org-compat.el
		    ./lisp/org/org-complete.el
   ORG-COMP.ELC   : ./lisp/org/org-compat.elc
		    ./lisp/org/org-complete.elc
   SEMANTIC.EL    : ./test/cedet/semantic-ia-utest.el
		    ./test/cedet/semantic-tests.el
		    ./test/cedet/semantic-utest-c.el
		    ./test/cedet/semantic-utest.el
   TESTSPPR.C     : ./test/cedet/tests/testsppreplace.c
		    ./test/cedet/tests/testsppreplaced.c

Do you see any errors in this report?  If so, we should fix GNU
doschk.  If not, that suggests that doschk is good enough for us
to use with Emacs, as part of a maintainer-mode check for problems
in this area.

>> From: Paul Eggert <eggert@cs.ucla.edu>
>> 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?
> 
> This is the complexity I want to avoid.  Don't you think it's
> complicated enough?

Having MS-DOS builders type two commands to extract, rather than one,
is not complicated.  It would be a tiny price to pay, compared to
the hassles for all developers who have to shoehorn file names into
the 8+3 straitjacket.  People who build for MS-DOS can be expected to
understand minor workarounds like this.

> And how about the issue with using slashes in the
> argument to djunpack?

What issue is that?  In the above instructions, djunpack's argument
does not contain any slashes.

> Scripts are written by people, who tend to err or miss something.

Sure, but a reasonable script will greatly lower the error rate to
something that is manageable.  That's all that one can ask of any
build system.

>> 'find' is already required to build Emacs; for example, Makefile.in
>> uses it.
> 
> Only lisp/Makefile.in, which is not used when a release is built on
> DOS (all the files are already compiled).

No, 'find' is used in other places too; for example it is used
the top level Makefile.in, and in leim/Makefile.in.  But my point,
which I think you're agreeing with, is that it's OK to use 'find'
in maintainer 'make' rules, since maintainers are expected to have hosts
with a decent toolset.

> This means, for example, that to test an
> arbitrary revision of the development tree, I will need to run
> make-dist on Unix, create a tarball, copy it to a DOS machine, then
> build, find problems, go back to the Unix machine, etc.

That's OK.  It's normal, even on Unix-like hosts to do that.
I do it all the time.  I've caught multiple bugs recently in
Emacs by doing that.

The goal is not to make _maintenance_ practical on MS-DOS; that
would be far too ambitious.  The goal is only to make _building_
practical on MS-DOS.

>> What else is needed?
> 
> Maintenance.

No matter what solution we adopt, some maintenance will be required.
However, if we can automate most of it, we will lessen the overall
maintenance burden.

> How can instructions that need to be googled for be simple and
> reliable?

Instructions don't *need* to be Googled for.  One can visit the Emacs
web page, and navigate to the installation instructions, which will be
one of the web pages that I mentioned.  However, it is quite common to
use Google nowadays, more common than traditional navigation, and
there's nothing wrong with that.

>>>> 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.
> 
> Which ones?

CEDET as well (see the above).  This is a continuing issue, with files
coming from multiple sources, and the problem is likely to keep
cropping up.  We need a better solution than what we've got now.