all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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 ;-).



  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.