all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
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 15:30:54 -0800	[thread overview]
Message-ID: <4D4DDDAE.3060401@cs.ucla.edu> (raw)
In-Reply-To: <83aaiaafiw.fsf@gnu.org>

On 02/05/2011 03:26 AM, Eli Zaretskii wrote:
>> If they do happen, we can deal with those problems by hand, as they
>> come up.
> 
> We do that now, and see where it got us.

Yes, right now "make dist" in the Emacs trunk doesn't obey the 8+3
restrictions.  My proposal would fix all six violations, automatically.

I'm trying to make it easier for mainstream developers to be largely
unaffected by DOS filename limits.  With a bit of luck this method
will work for all the file names developers are likely to add later.
But even if there are a few exceptions that require fixing by hand,
we'll still be much better off than we are now.

>> The remaining problems you mentioned seem to be largely theoretical.
> 
> Not if limitations on file names are lifted entirely.

I'm not proposing lifting *all* naming limitations.  Just lifting them
enough so that as a practical matter, non-DOS developers can almost
always stop worrying about this stuff.

>> We can easily give an option to override that, if necessary.
> 
> Then it _will_ be used, and the whole point is moot.

It's not moot.  It will be up to the person making the release to
decide whether a last-second 8+3 problem needs to be fixed before the
release is actually cut.  Releasers already have to make these sorts
of decisions; the change would help them do their job better, by
automating the checks.

>> That can be handled in the same way that the file-renaming is handled:
>> do the 'find' on Linux as part of the release process, distribute the
>> output of 'find' as a file, and have the DOS build procedure read that file.
> 
> More complications for the release process.

It's a small script, easily written, and reliable once written.

>> If the DOS procedure edits files in the proper order, the resulting
>> time stamps should be consistent with what 'make' expects.
> 
> I very much doubt that there exists a "proper order"

I don't see why not.  Any order that satisfies Make's dependencies
will do.  Just generate the files in the same order that 'make' does.

I see no significant technical impediment to the proposal.  If the
MS-DOS port is important enough to keep, then it's important enough to
improve its release process in this way, so that its 8+3 limits don't
continue to impede mainstream development.




  reply	other threads:[~2011-02-05 23:30 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
2011-02-05 11:20                                       ` Paul Eggert
2011-02-05 11:26                                         ` Eli Zaretskii
2011-02-05 23:30                                           ` Paul Eggert [this message]
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=4D4DDDAE.3060401@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=cyd@stupidchicken.com \
    --cc=eliz@gnu.org \
    --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.