From: Richard M K. <kr...@pr...> - 2007-01-23 01:19:37
|
Christophe Rhodes <cs...@ca...> writes: > Richard M Kreuter <kr...@pr...> writes: > >> * the feature testing done by :in-order-to ((... (feature ...))) >> doesn't support the composite feature expressions that read-time >> conditionals do. Is this omission intended? > > I'm not sure. I think I would support the inclusion of composite > expression support. The attached patch contains an implementation of a featurep, and uses it in traverse. >> * the in-order-to notation looks like it applies only to direct >> instances of the operation classes named in the defsystem form, and >> not to instances of subclasses (example below [*]). This seems like >> a bug; is it intended? > > That definitely looks wrong. A fix for this is also in the attached patch. >> * is there any other way to specify that the component-pathname of a >> module is the same as that of its parent other than the defsystem >> syntax :pathname "."? Does :pathname "." work the same way >> everywhere? > > For what it's worth, I believe the pedantically correct way of > indicating this is > :pathname #.(make-pathname :directory '(:relative)) > but I appreciate that this is a bit of a mouthful. Hrm. Would it objectionable to add a bit of syntax to defsystem for this case, e.g., ":pathname :parent"? (Not in the patch; just a suggestion.) As an additonal unimplemented suggestion, what would people think about making compile-op, load-source-op, and load-op all subclasses of a common class that denoted that the operation processes components as programs, rather than as mere files? For Lisp files, for example, this means that the operation might read, compile, load, or run the contents of the files; but merely copying, archiving, or updating the files from a VC system probably shouldn't be process-program-ops. This way, given inheritance of the in-order-to relation, the sorts of components that need feature conditionalization can be written like this: (:file "sbcl" :in-order-to ((process-program--op (feature :sbcl)))) rather than like this (:file "sbcl" :in-order-to ((compile-op (feature :sbcl)) (load-op (feature :sbcl)) (load-source-op (feature :sbcl)))) More importantly, third-party operations could be written as subclasses of process-program-op and so automagically be contingent on the same features as compile-op, load-op, and load-source-op. (At least one published third-party operation could take advantage of this, lint-op in Nikodemus Siivola's asdf-packaging-tools, which reads in source files with READ in order to check them.) Thanks, RmK |