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. _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel