From b02e59bc75dc693c66dc71df6fa3ad98da8e2e5f Mon Sep 17 00:00:00 2001 From: Daniel Barlow <> Date: Mon, 11 Feb 2002 14:01:49 +0000 Subject: [PATCH] Please ignore this commit --- README | 79 +++++++++++++++++++++++++++++++------------------------ asdf.lisp | 2 +- 2 files changed, 46 insertions(+), 35 deletions(-) diff --git a/README b/README index 40460ecd..e71e61d1 100644 --- a/README +++ b/README @@ -1,6 +1,6 @@ asdf: another system definition facility -*- Text -*- -$Id: README,v 1.7 2001/08/20 12:36:13 crhodes Exp $ +$Id: README,v 1.8 2002/02/11 14:01:49 dan_b Exp $ This system definition utility talks in terms of 'components' and 'operations'. @@ -90,10 +90,8 @@ happen one way or another. *** A name (required) -This is a string. It must satisfy the restrictions imposed on a -portable pathname character. - -[ This restriction is probably going away ] +This is a string. It must be a suitable value for the :name initarg +to make-pathname in whatever filesystem the system is to be found. *** a version identifier (optional, will default to parent's version) @@ -114,7 +112,7 @@ initargs, you can say must perform the load-system operation on each of "a" and "b", and before performing load-system, we have to load "foo" -This is pretty similar to what ACL defsystem does. mk-defsystem is +[ This is pretty similar to what ACL defsystem does. mk-defsystem is less general: it has an implied dependency for all x, (load x) depends on (compile x) @@ -122,7 +120,10 @@ less general: it has an implied dependency and using a :depends-on argument to say that b depends on a _actually_ means that - (compile b) depends on (load a) + (compile b) depends on (load a) + +This is insufficient for e.g. the McCLIM system, which requires that +all the files are loaded before any of them can be compiled ] In asdf, the dependency information for a given component and operation can be queried using (depends-on operation component), which @@ -144,6 +145,16 @@ the time for some CLISP hacking, I'm sure they'd welcome your fixes) Optional, may be inferred from name, type (the subclass of source-file), and location of parent. +The rules for this inference are: + +- the host is taken from the parent +- the pathname type is (rassoc classname *known-extensions* :test 'equal) +- the pathname case option is :local +- the pathname is merged against the parent + +[ Pathname case can be controlled by some per-component option whose +name I have not yet decided ] + Note that a component doesn't actually have any references to its parent, so this inference will only be valid in the context of a system operation (a special variable is bound to the location of @@ -156,22 +167,22 @@ the parent while a child is processed) A source file is any file that the system does not know how to generate from other components of the system. -(Note that this is not quite the same thing as "a file containing data -that is typically fed to a compiler". If a file is generated by some -pre-processor stage (e.g. a ".h" file from ".h.in" by autoconf) then -it is not, by this definition, a source file. Conversely, we might -have a graphic file that cannot be automatically regenerated, or a -proprietary shared library that we received as a binary: these do -count as source files for our purposes. All suggestions for better -terminology gratefully received) +(Note that this is not necessarily the same thing as "a file +containing data that is typically fed to a compiler". If a file is +generated by some pre-processor stage (e.g. a ".h" file from ".h.in" +by autoconf) then it is not, by this definition, a source file. +Conversely, we might have a graphic file that cannot be automatically +regenerated, or a proprietary shared library that we received as a +binary: these do count as source files for our purposes. All +suggestions for better terminology gratefully received) Subclasses of source-file exist for various languages. *** 'module', a collection of sub-components -This has extra slots :components and :default-component-class. -Most operations will not need to provide methods specialised on -modules, as the tree traversal happens automatically, +This has extra slots :components and :default-component-class. The +default operation knows how to traverse a module, so most operations +will not need to provide methods specialised on modules. A system object is usually a module. @@ -264,7 +275,7 @@ name is taken before a lookup is performed. When system definitions are loaded from .system files, a new scratch package is created for them to load into, so that different systems do not overwrite each others operations. The user may also wish -to include defpackage and in-package forms in his system definiton +to include defpackage and in-package forms in his system definition files, however, so that they can be loaded manually if need be. ** Syntax @@ -296,13 +307,7 @@ processed, but before the component in question has been compiled). The mk-alike :initially-do and :finally-do may be what you are looking for. -** shorthand for source-file components - -source-file components defined with (:file "a-string") or "a-string" -will have the string parsed into name and type as if it were a -filename, and an instance of the appropriate source-file subclass -created. If a type is not provided, it will default to the parent's -default component type. +How do we convert the defsystem form into a system? * Error handling @@ -318,11 +323,20 @@ OPERATION-ERROR TODO List ---------------------------------------------------------- + +defsystem is a macro that basically hands off its arguments to +parse-module-definition. parse-system-definition + + + * Outstanding spec questions, things to add ** Finding code: ":source-pathname " is not really good enough unless LPNs suddenly develop union filesystem semantics +[ We're looking to get the effect of search lists: "try here, here or +here" ] + ** case-sensitivity wrt filenames Convention is to refer to systems with symbols, which means they end @@ -331,10 +345,8 @@ up being named by uppercase strings. To find a .system file we system's customary case") which translates this uppercase into whatever case is nicest (lowercase for sbcl on unix) -For merging component names we use whatever the user supplied - -probably lowercase - and lowercase extensions, with :case :local. -This appears to work out fine, but but I haven't thought too hard -about it +We have excitingly chunky rules for merging component names, which +need to be documented. Oh, and implemented. ** symbols vs strings @@ -347,10 +359,6 @@ the package that they evaluate defsystem forms in <rahul> yeah, accidental interning could be a problem <Krystof> Which will then collide with the partition:partition symbol <Krystof> Hence (defsystem :partition ...) -<rahul> yeah - -actually I'm beginning to wonder if we shouldn't name _all_ components -with symbols and depend on :case :common to map them into customary case. ** defsystem syntax *** export process-option-list? @@ -370,6 +378,9 @@ instead of using parse-namestring (to avoid the problem that "foo.lisp" is an absolute directory when treated as an LPN). As it doesn't behave like a pathname, we shouldn't fool the user into thinking it is one +I think we should lose its funny behaviour and introduce a :type option + + * missing bits in implementation ** all of the above ** reuse the same scratch package whenever a system is reloaded from disk diff --git a/asdf.lisp b/asdf.lisp index a00c6074..fca5e22d 100644 --- a/asdf.lisp +++ b/asdf.lisp @@ -421,7 +421,7 @@ system.")) ;; ;; asdf:component is explicitly here to be shadowed later on. `(let ((component (or (cdr (gethash ,name *defined-systems*)) - (make-instance 'module :name ,name )))) + (make-instance 'module :name ,name )))) (setf (gethash ,name *defined-systems*) (cons 0 component)) (let (,@bindings) ; yes, I know this is the same as let ,bindings (reinitialize-instance component :name ,name ,@initargs)))))) -- GitLab