Re: defsystem vs asdf

Paolo Amoroso <[email protected]> Tue, 16 Aug 2005 22:14:05 +0200
Newsgroups gmane.lisp.clocc.general
Organization Paolo Amoroso - Milano, ITALY
Message-ID <[email protected]>
Sam Steingold <[email protected]> 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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf