From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: cyd@stupidchicken.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Compartmentalizing the 8.3 problem into the msdos directory
Date: Sat, 05 Feb 2011 12:59:43 +0200 [thread overview]
Message-ID: <83d3n6agrk.fsf@gnu.org> (raw)
In-Reply-To: <4D4680EE.2020404@cs.ucla.edu>
> Date: Mon, 31 Jan 2011 01:29:18 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: cyd@stupidchicken.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> 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 ;-).
next prev parent reply other threads:[~2011-02-05 10:59 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-23 12:15 Files from gnulib Eli Zaretskii
2011-01-23 12:40 ` Eli Zaretskii
2011-01-23 19:29 ` Paul Eggert
2011-01-23 22:16 ` Bruno Haible
2011-01-24 3:26 ` Stefan Monnier
2011-01-24 4:01 ` Eli Zaretskii
2011-01-24 23:26 ` Paul Eggert
2011-01-25 4:00 ` Eli Zaretskii
2011-01-25 8:48 ` Paul Eggert
2011-01-25 11:24 ` Eli Zaretskii
2011-01-25 11:32 ` Bastien ROUCARIES
2011-01-25 14:07 ` Eli Zaretskii
2011-01-25 18:07 ` Paul Eggert
2011-01-25 19:02 ` Eli Zaretskii
2011-01-25 21:03 ` Stefan Monnier
2011-01-25 21:54 ` Eli Zaretskii
2011-01-25 22:15 ` Stefan Monnier
2011-01-26 1:05 ` Paul Eggert
2011-01-26 4:12 ` Eli Zaretskii
2011-01-26 6:01 ` Eli Zaretskii
2011-01-26 15:19 ` Proposed gnulib renames [was: Files from gnulib] Eric Blake
2011-01-26 15:58 ` Proposed gnulib renames Eli Zaretskii
2011-01-26 17:33 ` Bruno Haible
2011-01-26 18:40 ` Eli Zaretskii
2011-01-26 19:01 ` Eric Blake
2011-01-26 19:01 ` Bruno Haible
2011-01-26 19:18 ` Eli Zaretskii
2011-01-27 7:37 ` Paul Eggert
2011-01-27 9:57 ` Eli Zaretskii
2011-01-27 9:58 ` Eli Zaretskii
2011-01-27 9:59 ` Bruno Haible
2011-01-28 1:57 ` Paul Eggert
2011-01-27 10:14 ` Bruno Haible
2011-01-27 10:23 ` Bruno Haible
2011-01-28 0:32 ` Paul Eggert
2011-01-26 16:11 ` Files from gnulib Stefan Monnier
2011-01-26 4:02 ` Eli Zaretskii
2011-01-26 0:32 ` Jason Rumney
2011-01-26 3:12 ` Stefan Monnier
2011-01-25 21:24 ` Paul Eggert
2011-01-25 22:06 ` Eli Zaretskii
2011-01-26 0:54 ` Paul Eggert
2011-01-26 4:10 ` Eli Zaretskii
2011-01-26 11:13 ` Jim Meyering
2011-01-26 13:09 ` Eli Zaretskii
2011-01-26 13:23 ` Jim Meyering
2011-01-26 13:29 ` Lennart Borgman
2011-01-26 13:33 ` Eli Zaretskii
2011-01-26 13:37 ` Eli Zaretskii
2011-01-26 13:50 ` Jim Meyering
2011-01-26 12:27 ` Andreas Schwab
2011-01-26 13:17 ` Eli Zaretskii
2011-01-26 13:24 ` Andreas Schwab
2011-01-26 13:41 ` Eli Zaretskii
2011-01-27 8:32 ` Paul Eggert
2011-01-27 11:08 ` Eli Zaretskii
2011-01-28 7:30 ` Paul Eggert
2011-01-28 14:20 ` Eli Zaretskii
2011-01-31 9:29 ` Compartmentalizing the 8.3 problem into the msdos directory Paul Eggert
2011-02-05 10:59 ` Eli Zaretskii [this message]
2011-02-05 11:20 ` Paul Eggert
2011-02-05 11:26 ` Eli Zaretskii
2011-02-05 23:30 ` Paul Eggert
2011-02-06 0:55 ` Glenn Morris
2011-02-06 13:37 ` Miles Bader
2011-02-06 4:01 ` Eli Zaretskii
2011-02-06 7:30 ` Paul Eggert
2011-02-06 9:59 ` Eli Zaretskii
2011-01-24 7:57 ` Files from gnulib Glenn Morris
2011-01-24 16:37 ` Stefan Monnier
2011-01-24 4:07 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83d3n6agrk.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=cyd@stupidchicken.com \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.