[asdf-devel] never ending component relative pathnames [2]

[Faré]

> i understand, that in some environments neither logical pathname
> designators nor logical pathnames themselves are seen as portable,
> but i continue to try to treat them as if they were. so far, with
> success. mostly.
>
I believe logical pathnames as defined in the CLHS are widely
supported, and if any implementation has bugs, then the implementation
should be fixed, not ASDF. However, they also have limitations, and if
you rely on more than what the specification provides, you're on your
own unless and until you get the spec fixed.

> if asdf was never intended to support such designators, that's also ok.
It was never. The only previously supported way that string could be
used as pathname designators was as file or directory names without
any directory separator, host or device specification. Now you can
also portably use / as a directory separator, but there is no way to
specify host or device or absolute pathname. Use #p... or
#.(make-pathname ...) for that.

> r. goldman had requested that i describe the breakage i had observed
> after i had pulled the then new asdf version.
> that is what this enumeration provided.
Thanks a lot, it is useful. But a distinction should be made between
supported cases and non-supported cases.

Now supported (1.630):
1- the name is a string or symbol (the name of which will be
downcased). It will be interpreted by merge-component-name-type as a
/-separated path, using the type specified by the component class if
any.
2- the :pathname specification overrides the name. It is interpreted
similarly if a symbol or a string. It can also be a pathname, in which
case it is not further interpreted.
3- the parent's pathname from is an absolute pathname, with proper
host and device.
4- the pathname obtained from 1 or 2 is merged with the one from 3 as
with merge-pathnames*, i.e. if it's relative, then the parent's host
and device are used.

Actually, now that we are using merge-pathnames* instead of
merge-pathnames, I find that the default argument to
merge-component-name-type becomes useless. Unless anyone objects, I
will remove it in ASDF 1.631 (and rename the function).

Regarding 2, note that the only portable ways to obtain a pathname are
a- #p"LOGICAL-HOST:logical;path;name"
b- #.(make-pathname ...)
c- More #. magic with merge-pathnames, *load-pathname*,
*load-truename*, (user-homedir-pathname), etc.

In particular, non-logical namestrings are NOT portable, MUST NOT be
used in a portable .asd file, and are otherwise not supported.


>> Therefore, I think the current behavior
>> is 100% better than the previous one. It indeed needs to be better
>> documented, though.
>
> that would be nice.
>
I can't find my way through the texinfo documentation. Too much manual
section management. Could we be using something nicer? ReST? Exscribe?
Gary King's CL-Markdown?

>> It would be nice if from your file was extracted a test for the
> if someone would enumerate the cases which are supported. i will try
> again.
> as i understand your demurral, relative to the tested enumeration[2],
> one should eliminate the cases which involve string designators for
> logical pathnames.
> should anything else be removed?
> are that any additional cases for which support should be tested?
>
Non-logical pathnames are out.
Namestrings without #p"..." are out.
Pathnames made with (make-pathname ...) are in.
/-separated pseudo-namestrings relative paths are in.
Tests should include cases where the source-file-type is "lisp", NIL
or :directory.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Politicians are like rats. What they steal for themselves is minuscule
compared to what they destroy getting it.