Sophie: sbcl-1.0.31-1mdv2010.0 i586

sbcl-1.0.31-1mdv2010.0.i586.rpm

<html lang="en">
<head>
<title>Inspiration - asdf Manual</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="asdf Manual">
<meta name="generator" content="makeinfo 4.13">
<link title="Top" rel="start" href="index.html#Top">
<link rel="prev" href="missing-bits-in-implementation.html#missing-bits-in-implementation" title="missing bits in implementation">
<link rel="next" href="Concept-Index.html#Concept-Index" title="Concept Index">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<!--
This manual describes asdf, a system definition facility for Common
Lisp programs and libraries.

asdf Copyright (C) 2001-2004 Daniel Barlow and contributors

This manual Copyright (C) 2001-2004 Daniel Barlow and
contributors

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
``Software''), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.-->
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
  pre.display { font-family:inherit }
  pre.format  { font-family:inherit }
  pre.smalldisplay { font-family:inherit; font-size:smaller }
  pre.smallformat  { font-family:inherit; font-size:smaller }
  pre.smallexample { font-size:smaller }
  pre.smalllisp    { font-size:smaller }
  span.sc    { font-variant:small-caps }
  span.roman { font-family:serif; font-weight:normal; } 
  span.sansserif { font-family:sans-serif; font-weight:normal; } 
--></style>
</head>
<body>
<div class="node">
<a name="Inspiration"></a>
<p>
Next:&nbsp;<a rel="next" accesskey="n" href="Concept-Index.html#Concept-Index">Concept Index</a>,
Previous:&nbsp;<a rel="previous" accesskey="p" href="missing-bits-in-implementation.html#missing-bits-in-implementation">missing bits in implementation</a>,
Up:&nbsp;<a rel="up" accesskey="u" href="index.html#Top">Top</a>
<hr>
</div>

<!-- node-name,  next,  previous,  up -->
<h2 class="chapter">9 Inspiration</h2>

<h3 class="section">9.1 mk-defsystem (defsystem-3.x)</h3>

<p>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 pre-ANSI implementations, which is
no longer necessary.

   <p>The surface defsystem syntax of asdf is more-or-less compatible with
mk-defsystem, except that we do not support the <code>source-foo</code> and
<code>binary-foo</code> prefixes for separating source and binary files, and
we advise the removal of all options to specify pathnames.

   <p>The mk-defsystem code for topologically sorting a module's dependency
list was very useful.

<h3 class="section">9.2 defsystem-4 proposal</h3>

<p>Marco and Peter's proposal for defsystem 4 served as the driver for
many of the features in here.  Notable differences are:

     <ul>
<li>We don't specify output files or output file extensions as part of the
system.

     <p>If you want to find out what files an operation would create, ask the
operation.

     <li>We don't deal with CL packages

     <p>If you want to compile in a particular package, use an in-package form
in that file (ilisp / SLIME will like you more if you do this anyway)

     <li>There is no proposal here that defsystem does version control.

     <p>A system has a given version which can be used to check dependencies,
but that's all. 
</ul>

   <p>The defsystem 4 proposal tends to look more at the external features,
whereas this one centres on a protocol for system introspection.

<h3 class="section">9.3 kmp's &ldquo;The Description of Large Systems&rdquo;, MIT AI Memu 801</h3>

<p>Available in updated-for-CL form on the web at
<a href="http://world.std.com/~pitman/Papers/Large-Systems.html">http://world.std.com/~pitman/Papers/Large-Systems.html</a>

   <p>In our implementation we borrow kmp's overall PROCESS-OPTIONS and
concept to deal with creating component trees from defsystem surface
syntax.  [ this is not true right now, though it used to be and
probably will be again soon ]

<!--  -->
   </body></html>