From: Paolo A. <am...@mc...> - 2005-08-16 20:14:10
|
Sam Steingold <sd...@gn...> writes: > since ASDF was created _after_ DEFSYSTEM, apparently it addresses some > problems with DEFSYSTEM (which ones?) and does not carry the same From the ASDF README file: asdf is extensible to new operations and to new component types. This allows the addition of behaviours: for example, a new component could be added for Java JAR archives, and methods specialised on compile-op added for it that would accomplish the relevant actions. * Inspiration ** mk-defsystem (defsystem-3.x) We aim to solve basically the same problems as mk-defsystem does. However, our architecture for extensibility better exploits CL language features (and is documented), and we intend to be portable rather than just widely-ported. No slight on the mk-defsystem authors and maintainers is intended here; that implementation has the unenviable task of supporting non-ANSI implementations, which I propose to ignore. The surface defsystem syntax of asdf is more-or-less compatible with mk-defsystem The mk-defsystem code for topologically sorting a module's dependency list was very useful. ** defsystem-4 proposal Marco and Peter's proposal for defsystem 4 served as the driver for many of the features in here. Notable differences are - we don't specify output files or output file extensions as part of the system If you want to find out what files an operation would create, ask the operation - we don't deal with CL packages If you want to compile in a particular package, use an in-package form in that file (ilisp will like you more if you do this anyway) - there is no proposal here that defsystem does version control. A system has a given version which can be used to check dependencies, but that's all. The defsystem 4 proposal tends to look more at the external features, whereas this one centres on a protocol for system introspection. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log |