Commit b02e59bc authored by Daniel Barlow's avatar Daniel Barlow
Browse files

Please ignore this commit

parent c795da47
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
......
......@@ -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))))))
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment