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

[james anderson]

good evening;

On 2010-03-08, at 17:53 , Faré wrote:

> Dear James,
>
> On 8 March 2010 11:08, james anderson <james.anderson at 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