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.