> Based on the experience from GDB, here are the problems with this
> approach:
> . The remapping of file names cannot be fully automated. Once all
> limits on file names are removed ("we don't want even the
> slightest impediment", says Jim), sooner or later you get to the
> point where the number of files to be renamed becomes large and a
> human needs to define how files will be renamed, because you want
> names that at least remotely resemble the original ones, but still
> don't clash in the 8+3 namespace. (I hope no one is seriously
> entertaining the idea of producing meaningless names like
> foo~123.c or ABC123EF.c, from some hash or whatever).
Yes, I was assuming that there would still be few files, and that the
renaming would be human-controlled (but the make-dist script signals an
error if the human-provided rules don't cover all cases). So it
wouldn't help for cases like CEDET.
> . Once the remapping is maintained by humans, it becomes unreliable.
Why is that?
> . The unpacking instructions are part of the tarball, and need to be
> extracted separately before the "main" extraction begins. More
> importantly, the remapping file needs to be extracted before that
> as well. This makes the entire unpacking procedure extremely
> complicated and thus error-prone, except if the person who does
> that is the one who designed it and wrote the instructions in the
> first place.
Rather than distribute a file that needs to be passed to djtar, I was
thinking of distributing a script tailored to MS-DOS, run instead of
djtar, and which would run djtar insternally. So this script can
provide the instructions.
> In addition, there will be a need to deal with something that the GDB
> distribution doesn't. In GDB, the files that are renamed during
> unpacking are only those that are not used for the DOS build. By
> contrast, here we want to rename files that are used during the build.
Yes, that's a much bigger problem.
In the mean time, please rename the files, thank you,
Stefan
