Re: Compartmentalizing the 8.3 problem into the msdos directory

[Paul Eggert]

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.