Re: Compartmentalizing the 8.3 problem into the msdos directory

[Paul Eggert <eggert@cs.ucla.edu>]

On 02/05/2011 02:59 AM, Eli Zaretskii wrote:

>  . It will effectively block a release, until msdos/fnchange.prs is
>    fixed.

We can easily give an option to override that, if necessary.  But the
idea is that such an option should not be needed, because the normal
state of affairs is that fnchange.prs should be sufficiently
up-to-date.  Even if (due to some last-second screwup) it's not
up-to-date, fnchange.prs is easy enough for the releaser to fix
without knowing all the ins and outs of MS-DOS 8+3 rules.

>    . 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.

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.
This essentially removes the potential for error that you mentioned.

>    . Editing files generally changes their time stamps, which could
>      then trigger Make rules not intended to run at end-user build
>      time

If the DOS procedure edits files in the proper order, the resulting
time stamps should be consistent with what 'make' expects.


The remaining problems you mentioned seem to be largely theoretical.
They might occur if we start to use unusually tricky file names, but
these problems don't exist now and are unlikely to occur.  If they do
happen, we can deal with those problems by hand, as they come up.
Ordinarily long file names shouldn't trigger any of those problems.