Re: Files from gnulib

[Eli Zaretskii]

Note: I removed gnulib from the list of addressees, as this is no
longer a gnulib issue.

> Date: Thu, 27 Jan 2011 00:32:03 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden, address@hidden, 
>  address@hidden
> 
> 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.

AFAIR, ARI calls doschk, or maybe there was some wrapper script that
did that.  But doschk is definitely used for this.

> 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

I emailed the Org mode maintainers yesterday (off-list), and they
agreed to rename org-complete.el to org-pcomplete.el (which is a more
correct name anyway, IMO).  The Emacs trunk will get that change when
it is sync'ed with Org next time.

>    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

These clashes are not important, because the test suite should not be
part of the release tarball.  (I know that currently it is, but Stefan
said that this is a bug that should be fixed.)

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

doschk is definitely good enough.

I do run doschk from time to time, and it seemed to be frequently
enough.  The issue is only important when a release is close.

In any case, the problem is not with having a Make target (the command
is trivial), but to arrange for someone or something to run it and
report the results.  Frankly, I never pushed that issue because people
tend to get annoyed by 8+3, so having something automatic that would
print messages about that didn't seem like a good idea...

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

I'm not talking about the number of commands, I'm talking about the
complexity of the first one and the potential to make mistakes in it.
Few DJGPP users even know about the -p and -o switches to djtar.
(djtar is generally used with only -x.)  If you use the command-line
arguments in a different order, chances are the command will not work
as intended.  I myself need to consult the README when I unpack the
GDB tarball, for fear of mistakes (which did happen), and I wrote that
stuff!


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

The argument could include slashes if the tarball is in a different
directory.  See the comments near the beginning of djunpack.bat.

> >> '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

Not relevant, as the DOS build doesn't use the top-level Makefile.in.
See config.bat and msdos/mainmake.v2.

> and in leim/Makefile.in

Not relevant, since this use in the `install' target which isn't run
on DOS (because "make install" in mainmake.v2 installs the binary
in-place, under the source tree, and thus doesn't recurse into leim/).

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

Yes, I agree.  However, those comments of mine were to your suggestion
to rename the files as part of running config.bat, which is run at
configure time on the end-user machines.  If you now have something
else in mind, those comments are probably not pertinent anymore.

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

You don't realize how little time I have to work on Emacs in general
and on the MS-DOS port in particular.  Each such complication steals
precious time that I don't have.  The Unix machine I use is fencepost,
so copying files involves moving them through the Internet.  Which
means I cannot do this offline (yes, connectivity problems do happen
in my corner of the world) or when fencepost is down, and also slows
down things quite a lot even if the connection is in good shape.

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

So now I'm supposed to lobby Emacs maintainers to have MS-DOS build
instructions on the Web site?  We've just heard several people ask
when it will be possible to drop the MS-DOS support entirely; how
would they react, you think, if I made such a request?  I generally
tend to avoid unnecessary friction wrt the MS-DOS port; I'm sure you
will understand after the experience of this thread.  msdos/INSTALL is
all I need, thank you.  It lies low and out of sight, and doesn't
bother anyone.

> However, it is quite common to use Google nowadays, more common than
> traditional navigation, and there's nothing wrong with that.

If you are looking for precise and correct instructions, googling is
your enemy, because it brings hits that cannot be guaranteed to be
correct.  Someone said something a year ago, and it's there forever,
even if in the meantime things happened that made it false.

Look, it's pointless to try to push further the possibility that Emacs
will adopt the same way of unpacking as GDB.  I invented that stuff in
the first place, but after all these years my experience with it is so
bad that I will never agree to have it in Emacs.  If the issue of
file-name clashes becomes so unbearable for the Emacs developers that
they will request that all limitations on file names are
unconditionally lifted, it will be easier for me to declare that the
MS-DOS port is dead, as soon as the conflicts hit the point where it
cannot be handled by simple tricks.

> >> I meant all the other files that have 8+3 issues.
> > 
> > Which ones?
> 
> CEDET as well (see the above).

Not an issue (see 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.

Experience shows that these issues crop up very rarely, although the
nervous reactions and the futile prolonged debates make it sound like
a grave problem.  I'm willing to consider any reasonable solutions to
that nonetheless, just not this one, because unlike any others, this
one is tested in practice, and it failed that test.