[m-rev.] for review and benchmarking: speed up file name creation in write_deps_file.m

[Zoltan Somogyi]

On 2023-09-08 16:44 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> Making dir./ more understandable is good, but it's not about mangling.
> 
> dir./ tries to return a valid path for a given FileName relative to a
> starting point of DirName. If FileName itself is an absolute path
> (or a drive-relative path), it's not obvious what the result should be,
> so dir./ throws an exception. You can't mangle an absolute path into a
> relative path.
> 
> The other thing dir./ does is produce a normalised path, in that the
> result path uses the standard separator for the platform, and does not
> include redundant directory separators. (I had thought it might attempt
> to do something with "." or ".." components but it does not.)

This "other thing" is what I was referring to by "mangling". Sloppy usage, I know.

I like the term "normalised"; it is (in this case) a synonym for "canonicalised",
but shorter. We should include it in the name of any test predicate.

There is something I don't understand about cygwin's use of directory separators.
(I pretty much know nothing about cygwin in general, by design.) The comments
say that cygwin distinguishes between // and \\ as the root directories of two
different systems, but does it distinguish between / and \ in any other contexts?
If not, then shouldn't canonicalisation/normalisation replace the alt separator
with the main separator in all other contexts?

>> - add dir.relative_path_from_unchecked_components (which would be
>>   the current relative_path_from_components, renamed) which is
>>   documented to require its callers to ensure those same conditions.
> 
> This one is okay.

Thanks.

Zoltan.