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

[Peter Wang]

On Fri, 08 Sep 2023 12:03:15 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> On 2023-09-07 15:05 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> 
> > I introduced relative_path_name_from_components specifically to be fast
> > when you KNOW the list elements are simple directory components, and you
> > only want a relative path name. Directory separators, drive letters, ., ..,
> > and any other stuff that dir./ tries to deal with are out of scope as it
> > would slow down relative_path_name_from_components for the case that is
> > it designed for. We can make that clearer in the documentation as you
> > say.
> 
> At the moment, dir./ has a complicated structure, that does not make clear
> exactly what requirements it imposes on its two operands. I think we should
> 
> - create a predicate for checking whether the second arg of dir./
>    already meets the requirements
> - create a predicate for mangling a string into meeting those requirements
> - create two more such predicates for the first arg
> - create a predicate for checking whether a string meets the requirements
>   of *both* args in dir./, if this would not duplicate one of the earlier ones
> - create a predicate for mangling a string into meeting both requirements
> - document that dir.relative_path_from_components mangles the
>   first dir name on its list to meet the requirements of both args of dir./
>   and mangles all the other list elements to meet the requirements of
>   the second arg

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

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

Peter