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

[james anderson]

On 2010-03-10, at 00:49 , Faré wrote:

> Dear James,
>
>> [ ... ]
>
>> 2. the description of the interaction between a :pathname
>> specification and a default file type was not clear.
>>    i added various combinations to the tests.
>>    please advise as to which ones are intended to be supported.
>>
> root should be (make-pathname :name nil :type nil :version nil
> :defaults *load-pathname*)

=> add *load-pathname* to the systems pathname argument and to create  
the target tree in the working directory.

> These are not currently portably valid:
> * module "./"

=> remove these entries.
elsewhere it is described that "." should work.
? add entries for "." to the module and system lists?

>
> For completeness, these should be added:
> * system nil (default from *load-truename*)
> * module "module2/submodule1/"
> * module "module2/submodule1" (same as above, without ending /)
> * for completeness, "module2/submodule4.foo/" and "module2/ 
> submodule4.foo"

=> ok. i understand these four, above.

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

> * similarly for absolute path as a string.

? do not understand
>
>> 3. neither the syntax nor the semantics of the "lisp",
>> nil, :directory use cases is clear.
>>
> Yes, it hasn't been documented so far. My bad. At least it now has a
> well-defined meaning, as opposed to the previous mess.
> a- when the source-file-type of a component is NIL, then the file type
> is read from the last /-separated component of the string as the last
> dot-separated component (unless there's only one dot and  it's the
> first character, in which case the type is NIL and that's the name).
> b- when the source-file-type of a component is a string, then it will
> be the type, and the last /-separated component of the string provides
> the name.
> c- when the source-file-type of a component is :DIRECTORY, then all
> /-separated components of the string including the last one are
> interpreted as directories.

? but not when it is a file or file specialization?

>
>
>>> 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.
>>
>> if "overrides" and "not further interpreted" are intended to mean,
>> that the :pathname specification must include any eventual file type,
>> then the documentation should be _very_ clear about that. from my
>> first look at the test results, it seems that this restriction
>> applies, but i am still uncertain. (see [2] above)
>>
> Yes, currently, that's the case. That's how we allow the user
> to have fine-control over the file type when he so desires.
> If you want control you can have it - use pathnames and you're
> on your own. If you want automation, use a string and let ASDF
> parse it the way that makes obvious sense. But you're right, it's
> one more thing that needs to be documented. Sigh.

discussed further in later messages...

> [ ... ]
>> please describe the syntax for pathname pseudo-namestrings.
>> i have added pathname specifications to the tests[3] which mirror
>> clhs 19.3.1, but
>> a. use '/' instead of ';' as the (relative)-directory-marker;
>> b. follow the unix convention for "relative" rather than the logical
>> pathname convention;
>> c. exclude hosts
>>
>> is that the intended syntax?
>>
> Yes. Plus the fact that either a type is provided by the component  
> class,
> or none is and the type is taken from the string.

? still no clear one this. please describe a few examples with the  
intended effective component pathname.