good evening;
On 2010-03-08, at 17:53 , Faré wrote:
Dear James,
On 8 March 2010 11:08, james anderson james.anderson@setf.de wrote:
please find referenced below, a suggestion as to the use cases which the component pathname computation should support.[1]
specifying :pathname arguments to ASDF components as strings had NEVER been working portably before ASDF 1.630.
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.
The current behavior might not fit all the non-portable expectations that someone or some other might have fancied at some point, but 1- it is now portable, and 2- any previous non-portable expectation can still achieved with a simple #p prefix to your namestring.
that adjustment to the problematic .asd had, in fact, brought it in line with the changed asdf behaviour. if asdf was never intended to support such designators, that's also ok. 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.
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.
It would be nice if from your file was extracted a test for the actually supported combinations. I'd include that in the ASDF test suite. As for the non-supported combinations, well, they are not supported, never have been, and probably never will.
Note interestingly that #p"..." pathnames other than logical pathnames are not portable either, are not supported, and should NOT be tested in the test-suite.
i did not intend for there to have been any. i did not think that there were.
- if a logical pathname is specified as a string, it is not
correctly coerced to a logical pathname. in sbcl it causes an error. in ccl the pathname is wrong.
Not supported. Never will be. Please use #p for that.
- if a relative pathname is specified for a source file, either the
file name is missing in the component pathname or the type is missing depending on the declaration.
Can you give an example?
there may be some combinations for which the expected target is wrong
- with the consequent false positive/negative.
if one could eliminate the systematic failures, should any still remain, we can look again.
If you can produce a list of failures in cases that should be supported, that'd be great.
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?
--- [1] : http://github.com/lisp/de.setf.graphics/blob/master/graphics.asd [2] : http://github.com/lisp/de.setf.asdf.x/blob/master/test/cp- test.lisp