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

[Faré]

On 10 March 2010 09:41, james anderson <james.anderson at setf.de> wrote:
>>>> These are not currently portably valid:
>>>> * module "./"
>>>
> ok. ? i don't put them in. or, i put them in and (as i need to
> anyway) add machinery to verify error cases?
>
Don't put them in, since we don't currently catch such non-portability.

>>>> * source test to be split between :file lisp module and :static-
>>>> file data file
>>>> * :file "file2.lisp" means #p"file2.lisp.lisp"
>>>> * :static-file "file2.lisp" means #p"file2.lisp"
>>>> * :file "module1-1/file3.lisp" means #p"module1-1/
>>>> file3.lisp.lisp" (assuming /)
>>>> * :static-file "module1-1/file3.lisp" means #p"module1-1/file3.lisp"
>>>
>>> ? == add a :static-file as a sibling to the :file component
>>> ? == add combinations for variations in the component name
>>>
>> add :static-file as a sibling, and note that various things behave
>> differently, since :file always adds .lisp to a specified string
>> whereas :static-file never adds anything (and neither ever substract).
>
> i think i finally am not unclear about this.
>
Then don't bother for now. If the thing gets integrated in the ASDF test
suite I may extend it later.

>>>> * similarly for absolute path as a string.
>>> ? do not understand
>> We probably want to check that these work (at least on Unix):
>> "/foo/bar/baz.quux"
>
> still do not completely understand. i need a matrix
>
Will do, eventually. In what SEXP format?

> i have fabricated a mechanism to verify the results, but - while i am
> no longer completely unclear, i am not certain what the intended
> values are.
OK.

> especially since the two column regions are not independent and it's
> actually a 3-d table.
> plus the interaction because leaf component values are not
> independent of module and system values.
>
> the assertions in component-pathname-test.lisp were (and remain) just
> my best guesses.
>
> if one could fill out a table like this (yes, somehow n-dimensional)
> with a performance specification in each cell for which support is
> intended, i would be very happy.
>
Or cheat, and make all the results the same, varying the input as necessary
so that each combo is fulfiiled.

Alternatively, you could start extracting the current results from a
run of the code, then we could double check that all results are expected.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The problem with being a citizen of the world is
that you don't get to travelling abroad much.