Re: Compartmentalizing the 8.3 problem into the msdos directory

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 01:29:18 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> 
> On 01/28/2011 06:20 AM, Eli Zaretskii wrote:
> 
> > Then perhaps I don't understand your suggestion.  Could you describe
> > it in its entirety, starting with how file-name clashes would be
> > detected, how their alternative names would be determined, and how all
> > this would work with make-dist and configuring and building the MS-DOS
> > port?
> 
> Here's how it works.

Thanks.  Here are the main difficulties I see with this method:

 . It will effectively block a release, until msdos/fnchange.prs is
   fixed.  I doubt that release managers will like that.  To unblock
   the release, they will have to negotiate with me, because alternate
   file names cannot be arbitrary.  (This is unlike in GDB, where the
   renamed files are not used in the MS-DOS build, and so their
   alternate names can be anything at all.)  I don't think I want to
   be a road block for Emacs releases: what if I'm sick or off line
   for several days?

 . The proposed fncheck.sh script will rename files regardless of
   their directories, which might cause gratuitous problems, if the
   same basename happens in more than one directory, but causes
   file-name clashes only in one of them.

 . The script that is to be run at MS-DOS configure time, the one you
   left as an exercise, is tricky to write at best, for the following
   reasons:

   . It needs to run on plain DOS, and so can only use features
     supported by the extremely primitive command.com shell available
     there.  For example, it cannot even recurse through arbitrary
     directory trees.

     The Emacs build procedure for MS-DOS makes a point of not using
     any ported GNU software, such as Bash or Findutils, for which
     replacements are not easily available, because Emacs is one of
     the few packages that need to be built first to bootstrap the
     DJGPP development environment.  Currently, only rm, mv, cp, and
     Sed are required, in addition to Make and a working compiler.
     (This is unlike GDB, which already requires Bash, Coreutils, and
     Findutils.)

     To make this script possible without requiring more ported tools,
     we will need to have some database of directories into which to
     look and files in those directories to edit.  This means more
     manually maintained files and more potential for errors.

   . It's not clear, in general, how to replace original names with
     alternative ones.  Different types of files (Makefile.in, C
     sources, Lisp sources, auto-generated files) that refer to
     renamed ones might require different ways of editing them.

     For example, files in etc/themes assume that the name of the file
     matches the name of the theme itself, so we will need to edit the
     `provide' line as well, and then any `require' lines elsewhere.
     
     As another example, various Makefile's could use shell trickery,
     such as mentioning "*.info-*" wildcards, which needs implicitly
     to be edited without any file by that name present anywhere, so
     doschk will not catch that.

     The rules to support those non-trivial issues will have to be
     maintained manually: more potential for errors.

   . Editing files generally changes their time stamps, which could
     then trigger Make rules not intended to run at end-user build
     time (e.g., generation of Makefile.in from Makefile.am).  Keeping
     the original file times requires additional tools such as GNU
     `touch'.

So, by and large, I'd prefer to avoid these complications as much as
possible.  If I'm faced with the choice to drop MS-DOS build support
or use this method, I might reconsider, but even then it's quite
possible I will decide to give up rather than plunge into this
adventure.  As long as the head maintainers don't force me to face
that choice, I'm unwilling to add all this complexity to the task of
maintaining the DOS port, which currently takes a small fraction of my
time (even if we count in the occasional dispute such as the one which
led to this thread ;-).