[asdf-devel] never ending component relative pathnames

[james anderson]

good afternoon;

On 2010-03-05, at 21:35 , Robert Goldman wrote:

> On 3/5/10 Mar 5 -2:18 PM, james anderson wrote:
>> i would be as well.
>>
>> that's why i sent it to you at the other end of a link.
>
> I followed the link to the diff.  What more should I have seen?
>
> Also, it would be helpful if you would describe precisely the breakage
> you have observed (what precisely happened to the module pathnames?).
>
> In that case, we can abstract a simpler version and turn it into a  
> test
> case.  We can't reverse engineer such a test case out of the  
> description
> below, and it's probably expecting too much for us to pull your git  
> repo
> and try to build it just in order to extract a bug.
>
> Would it be possible for you to reformulate this as a launchpad bug?

please find enclosed suggestion as to the use cases which the  
component pathname computation should support.
it is formulated as a test, whether the component pathname for each  
of the system, module, and source file component in a minimal system  
definition does in fact locate the intended directory or file given  
combinations of component name and :pathname argument in the  
respective system declaration. for each combination this tests the  
system directory pathname, module directory pathname the actual  
source file pathname and that pathname with an explicit type default.

i attach also the results for sbcl and ccl based on asdf >= 1.630

in all there are more than a thousand combinations. of these i  
observe two systematic failures.

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

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cp-test.lisp
Type: application/applefile
Size: 545 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100307/bbf734a2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cp-test.lisp
Type: application/octet-stream
Size: 9774 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100307/bbf734a2/attachment.obj>
-------------- next part --------------


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cp-test-results-fasl.txt
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100307/bbf734a2/attachment.txt>
-------------- next part --------------


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cp-test-results-dfsl.txt
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100307/bbf734a2/attachment-0001.txt>
-------------- next part --------------