[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compartmentalizing the 8.3 problem into the msdos directory
From: |
Eli Zaretskii |
Subject: |
Re: Compartmentalizing the 8.3 problem into the msdos directory |
Date: |
Sat, 05 Feb 2011 12:59:43 +0200 |
> 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 ;-).
- Re: Compartmentalizing the 8.3 problem into the msdos directory,
Eli Zaretskii <=