On 2010-03-10, at 00:49 , Faré wrote:
Dear James,
[ ... ]
- 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
- 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.