cleaned up packages a bit more.
[CommonLispStat.git] / external / asdf_README.txt
blobb55c5f0f681a779ccfb85b60abb64bb6a8692744
1 $Id: README,v 1.39 2006/08/21 10:52:32 crhodes Exp $         -*- Text -*-\r
2 \r
3 The canonical documentation for asdf is in the file asdf.texinfo.  \r
4 The significant overlap between this file and that will one day be\r
5 resolved by deleting text from this file; in the meantime, please look\r
6 there before here.\r
7 \r
8 \r
9 \r
10 asdf: another system definition facility          \r
11 ========================================\r
13 * Getting the latest version\r
15 0) Decide which version you want.  HEAD is the newest version and\r
16 usually OK, whereas RELEASE is for cautious people (e.g. who already\r
17 have systems using asdf that they don't want broken), a slightly older\r
18 version about which none of the HEAD users have complained.\r
20 1) Check it out from sourceforge cCLan CVS:\r
22 1a) cvs -d:pserver:anonymous@cvs.cclan.sourceforge.net:/cvsroot/cclan login\r
23      (no password: just press Enter)\r
24  \r
25 1a.1) cvs -z3 -d:pserver:anonymous@cvs.cclan.sourceforge.net:/cvsroot/cclan\r
26          co -r RELEASE asdf\r
28 or for the bleeding edge, instead\r
30 1a.2) cvs -z3 -d:pserver:anonymous@cvs.cclan.sourceforge.net:/cvsroot/cclan\r
31           co -A asdf\r
33 If you are tracking the bleeding edge, you may want to subscribe to\r
34 the cclan-commits mailing list (see\r
35 <URL:http://sourceforge.net/mail/?group_id=28536>) to receive commit\r
36 messages and diffs whenever changes are made.\r
38 For more CVS information, look at http://sourceforge.net/cvs/?group_id=28536\r
41 * Getting started\r
43 - The single file asdf.lisp is all you need to use asdf normally.  For\r
44 maximum convenience you want to have it loaded whenever you start your\r
45 Lisp implementation, by loading it from the startup script, or dumping\r
46 a custom core, or something.\r
48 - The variable asdf:*central-registry* is a list of system directory\r
49   designators.  A system directory designator is a form which will be\r
50   evaluated whenever a system is to be found, and must evaluate to a\r
51   directory to look in.  For example, you might have\r
53      (*default-pathname-defaults* "/home/me/cl/systems/"\r
54       "/usr/share/common-lisp/systems/")\r
56   (When we say "directory" here, we mean "designator for a pathname\r
57   with a supplied DIRECTORY component")\r
59   It is possible to customize the system definition file search.\r
60   That's considered advanced use, and covered later: search forward\r
61   for *system-definition-search-functions*\r
63 - To compile and load a system 'foo', you need to (1) ensure that\r
64   foo.asd is in one of the directories in *central-registry* (a\r
65   symlink to the real location of foo.asd is preferred), (2) execute\r
66   ``(asdf:operate 'asdf:load-op 'foo)''\r
68     $ cd /home/me/cl/systems/\r
69     $ ln -s ~/src/foo/foo.asd .\r
70     $ lisp\r
71     * (asdf:operate 'asdf:load-op 'foo)\r
73 - To write your own system definitions, look at the test systems in\r
74   test/ , and read the rest of this.  Ignore systems/ which is old\r
75   and may go away when next I clean up\r
77 - Syntax is similar to mk-defsystem 3 for straightforward systems, you\r
78   may only need to remove the :source-pathname option (and replace it\r
79   with :pathname if the asd file is not in the same place as the\r
80   system sources)\r
82 - Join cclan-list@lists.sf.net for discussion, bug reports, questions, etc\r
84 - cclan.asd and the source files listed therein contain useful extensions \r
85   for maintainers of systems in the cCLan.  If this isn't you, you\r
86   don't need them - although you may want to look at them anyway\r
88 - For systems that do complicated things (e.g. compiling C files to\r
89   load as foreign code), the packages in vn-cclan may provide some\r
90   guidance.  db-sockets, for example, is known to do outlandish things\r
91   with preprocessors\r
93    http://ww.telent.net/cliki/vn-cclan \r
97 * Concepts\r
99 This system definition utility talks in terms of 'components' and\r
100 'operations'.\r
102 Components form systems: a component represents a source file, or a\r
103 collection of components.  A system is therefore a component,\r
104 recursively formed of a tree of subcomponents.\r
106 Operations are instantiated then performed on the nodes of a tree to\r
107 do things like\r
109  - compile all its files\r
110  - load the files into a running lisp environment\r
111  - copy its source files somewhere else\r
113 Operations can be invoked directly, or examined to see what their\r
114 effects would be without performing them.  There are a bunch of \r
115 methods specialised on operation and component type which actually do\r
116 the grunt work.\r
118 asdf is extensible to new operations and to new component types.  This\r
119 allows the addition of behaviours: for example, a new component could\r
120 be added for Java JAR archives, and methods specialised on compile-op\r
121 added for it that would accomplish the relevant actions.  Users\r
122 defining their own operations and component types should inherit from\r
123 the asdf base classes asdf:operation and asdf:component respectively.\r
125 * Inspiration\r
127 ** mk-defsystem (defsystem-3.x)\r
129 We aim to solve basically the same problems as mk-defsystem does.\r
130 However, our architecture for extensibility better exploits CL\r
131 language features (and is documented), and we intend to be portable\r
132 rather than just widely-ported.  No slight on the mk-defsystem authors\r
133 and maintainers is intended here; that implementation has the\r
134 unenviable task of supporting non-ANSI implementations, which I\r
135 propose to ignore.\r
137 The surface defsystem syntax of asdf is more-or-less compatible with\r
138 mk-defsystem\r
140 The mk-defsystem code for topologically sorting a module's dependency\r
141 list was very useful.\r
143 ** defsystem-4 proposal\r
145 Marco and Peter's proposal for defsystem 4 served as the driver for\r
146 many of the features in here.  Notable differences are\r
148 - we don't specify output files or output file extensions as part of\r
149   the system\r
151   If you want to find out what files an operation would create, ask\r
152   the operation\r
154 - we don't deal with CL packages\r
156   If you want to compile in a particular package, use an in-package\r
157   form in that file (ilisp will like you more if you do this anyway)\r
159 - there is no proposal here that defsystem does version control.  \r
161   A system has a given version which can be used to check\r
162   dependencies, but that's all.\r
164 The defsystem 4 proposal tends to look more at the external features,\r
165 whereas this one centres on a protocol for system introspection.\r
167 ** kmp's "The Description of Large Systems", MIT AI Memu 801\r
169 Available in updated-for-CL form on the web at \r
170 http://world.std.com/~pitman/Papers/Large-Systems.html\r
172 In our implementation we borrow kmp's overall PROCESS-OPTIONS and\r
173 concept to deal with creating component trees from defsystem surface\r
174 syntax.  [ this is not true right now, though it used to be and\r
175 probably will be again soon ]\r
178 * The Objects\r
180 ** component\r
182 *** Component Attributes\r
184 **** A name (required)\r
186 This is a string or a symbol.  If a symbol, its name is taken and\r
187 lowercased.  The name must be a suitable value for the :name initarg\r
188 to make-pathname in whatever filesystem the system is to be found.\r
190 The lower-casing-symbols behaviour is unconventional, but was selected\r
191 after some consideration.  Observations suggest that the type of\r
192 systems we want to support either have lowercase as customary case\r
193 (Unix, Mac, windows) or silently convert lowercase to uppercase\r
194 (lpns), so this makes more sense than attempting to use :case :common,\r
195 which is reported not to work on some implementations\r
197 **** a version identifier (optional)\r
199 This is used by the test-system-version operation (see later).\r
201 **** *features* required\r
203 Traditionally defsystem users have used reader conditionals to include\r
204 or exclude specific per-implementation files.  This means that any\r
205 single implementation cannot read the entire system, which becomes a\r
206 problem if it doesn't wish to compile it, but instead for example to\r
207 create an archive file containing all the sources, as it will omit to\r
208 process the system-dependent sources for other systems.\r
210 Each component in an asdf system may therefore specify features using\r
211 the same syntax as #+ does, and it will (somehow) be ignored for\r
212 certain operations unless the feature conditional matches\r
214 **** dependencies on its siblings  (optional but often necessary)\r
216 There is an excitingly complicated relationship between the initarg\r
217 and the method that you use to ask about dependencies\r
219 Dependencies are between (operation component) pairs.  In your\r
220 initargs, you can say\r
222 :in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))\r
223               (load-op (load-op "foo")))\r
225 - before performing compile-op on this component, we must perform\r
226 load-op on "a" and "b", and compile-op on c, - before performing\r
227 load-op, we have to load "foo"\r
229 The syntax is approximately\r
231 (this-op {(other-op required-components)}+)\r
233 required-components := component-name\r
234                      | (required-components required-components)\r
236 component-name := string\r
237                 | (:version string minimum-version-object)\r
239 [ This is on a par with what ACL defsystem does.  mk-defsystem is less\r
240 general: it has an implied dependency\r
242   for all x, (load x) depends on (compile x)\r
244 and using a :depends-on argument to say that b depends on a _actually_\r
245 means that\r
247   (compile b) depends on (load a) \r
249 This is insufficient for e.g. the McCLIM system, which requires that\r
250 all the files are loaded before any of them can be compiled ]\r
252 In asdf, the dependency information for a given component and\r
253 operation can be queried using (component-depends-on operation\r
254 component), which returns a list\r
256 ((load-op "a") (load-op "b") (compile-op "c") ...)\r
258 component-depends-on can be subclassed for more specific\r
259 component/operation types: these need to (call-next-method) and append\r
260 the answer to their dependency, unless they have a good reason for\r
261 completely overriding the default dependencies\r
263 (If it weren't for CLISP, we'd be using a LIST method combination to\r
264 do this transparently.  But, we need to support CLISP.  If you have\r
265 the time for some CLISP hacking, I'm sure they'd welcome your fixes)\r
267 **** a pathname\r
269 This is optional and if absent will be inferred from name, type (the\r
270 subclass of source-file), and the location of parent.\r
272 The rules for this inference are:\r
274 (for source-files)\r
275 - the host is taken from the parent\r
276 - pathname type is (source-file-type component system)\r
277 - the pathname case option is :local\r
278 - the pathname is merged against the parent\r
280 (for modules)\r
281 - the host is taken from the parent\r
282 - the name and type are NIL\r
283 - the directory is (:relative component-name)\r
284 - the pathname case option is :local\r
285 - the pathname is merged against the parent\r
287 Note that the DEFSYSTEM operator (used to create a "top-level" system)\r
288 does additional processing to set the filesystem location of the\r
289 top component in that system.  This is detailed elsewhere\r
291 The answer to the frequently asked question "how do I create a system \r
292 definition where all the source files have a .cl extension" is thus\r
294 (defmethod source-file-type ((c cl-source-file) (s (eql (find-system 'my-sys))))\r
295    "cl")\r
297 **** properties (optional)\r
299 Packaging systems often require information about files or systems\r
300 additional to that specified here.  Programs that create vendor\r
301 packages out of asdf systems therefore have to create "placeholder"\r
302 information to satisfy these systems.  Sometimes the creator of an\r
303 asdf system may know the additional information and wish to provide it\r
304 directly.\r
306 (component-property component property-name) and associated setf method \r
307 will allow the programmatic update of this information.  Property\r
308 names are compared as if by EQL, so use symbols or keywords or something\r
310 ** Subclasses of component\r
312 *** 'source-file'\r
314 A source file is any file that the system does not know how to\r
315 generate from other components of the system. \r
317 (Note that this is not necessarily the same thing as "a file\r
318 containing data that is typically fed to a compiler".  If a file is\r
319 generated by some pre-processor stage (e.g. a ".h" file from ".h.in"\r
320 by autoconf) then it is not, by this definition, a source file.\r
321 Conversely, we might have a graphic file that cannot be automatically\r
322 regenerated, or a proprietary shared library that we received as a\r
323 binary: these do count as source files for our purposes.  All\r
324 suggestions for better terminology gratefully received)\r
326 Subclasses of source-file exist for various languages.  \r
328 *** 'module', a collection of sub-components\r
330 This has extra slots for\r
332  :components - the components contained in this module\r
334  :default-component-class - for child components which don't specify\r
335    their class explicitly\r
337  :if-component-dep-fails takes one of the values :fail, :try-next, :ignore \r
338    (default value is :fail).  The other values can be used for implementing\r
339    conditional compilation based on implementation *features*, where\r
340    it is not necessary for all files in a module to be compiled\r
342 The default operation knows how to traverse a module, so most\r
343 operations will not need to provide methods specialised on modules.\r
345 The module may be subclassed to represent components such as\r
346 foreign-language linked libraries or archive files.\r
348 *** system, subclasses module\r
350 A system is a module with a few extra attributes for documentation\r
351 purposes.  In behaviour, it's usually identical.\r
353 Users can create new classes for their systems: the default defsystem\r
354 macro takes a :classs keyword argument.\r
357 ** operation\r
359 An operation is instantiated whenever the user asks that an operation\r
360 be performed, inspected, or etc.  The operation object contains\r
361 whatever state is relevant to this purpose (perhaps a list of visited\r
362 nodes, for example) but primarily is a nice thing to specialise\r
363 operation methods on and easier than having them all be EQL methods.\r
365 There are no differences between standard operations and user-defined\r
366 operations, except that the user is respectfully requested to keep his\r
367 (or more importantly, our) package namespace clean\r
369 *** invoking operations\r
371 (operate operation system &rest keywords-args)\r
373 keyword-args are passed to the make-instance call when creating the\r
374 operation: valid keywords depend on the initargs that the operation is\r
375 defined to accept.  Note that dependencies may cause the operation to\r
376 invoke other operations on the system or its components: the new\r
377 operation will be created with the same initargs as the original one.\r
379 oos is accepted as a synonym for operate\r
381 *** standard operations\r
383 **** feature-dependent-op\r
385 This is not intended to be instantiated directly, but other operations\r
386 may inherit from it.  An instance of feature-dependent-op will ignore\r
387 any components which have a `features' attribute, unless the feature\r
388 combination it designates is satisfied by *features*\r
390 See the earlier explanation about the component features attribute for\r
391 more information\r
393 **** compile-op &key proclamations\r
395 If proclamations are supplied, they will be proclaimed.  This is a\r
396 good place to specify optimization settings\r
398 When creating a new component, you should provide methods for this.  \r
400 If you invoke compile-op as a user, component dependencies often mean\r
401 you may get some parts of the system loaded.  This may not necessarily\r
402 be the whole thing, though; for your own sanity it is recommended that\r
403 you use load-op if you want to load a system.\r
405 **** load-op &key proclamations\r
407 The default methods for load-op compile files before loading them.\r
408 For parity, your own methods on new component types should probably do\r
409 so too\r
411 **** load-source-op\r
413 This method will load the source for the files in a module even if the\r
414 source files have been compiled. Systems sometimes have knotty\r
415 dependencies which require that sources are loaded before they can be\r
416 compiled.  This is how you do that.\r
418 If you are creating a component type, you need to implement this\r
419 operation - at least, where meaningful.\r
421 **** test-system-version &key minimum\r
423 Asks the system whether it satisfies a version requirement.\r
425 The default method accepts a string, which is expected to contain of a\r
426 number of integers separated by #\. characters.  The method is not\r
427 recursive.  The component satisfies the version dependency if it has\r
428 the same major number as required and each of its sub-versions is\r
429 greater than or equal to the sub-version number required.\r
431 (defun version-satisfies (x y)\r
432   (labels ((bigger (x y)\r
433              (cond ((not y) t)\r
434                    ((not x) nil)\r
435                    ((> (car x) (car y)) t)\r
436                    ((= (car x) (car y))\r
437                     (bigger (cdr x) (cdr y))))))\r
438     (and (= (car x) (car y))\r
439          (or (not (cdr y)) (bigger (cdr x) (cdr y))))))\r
441 If that doesn't work for your system, you can override it.  I hope\r
442 yoyu have as much fun writing the new method as #lisp did\r
443 reimplementing this one. \r
445 *** Creating new operations\r
447 subclass operation, provide methods for source-file for \r
449 - output-files\r
450 - perform\r
451    The perform method must call output-files to find out where to\r
452    put its files, because the user is allowed to override output-files\r
453    for local policy\r
454 - explain\r
455 - operation-done-p, if you don't like the default one\r
457 * Writing system definitions\r
459 ** System designators\r
461 System designators are strings or symbols and behave just like\r
462 any other component names (including case conversion)\r
464 ** find-system\r
466 Given a system designator, find-system finds an actual system - either\r
467 in memory, or in a file on the disk.  It funcalls each element in the\r
468 *system-definition-search-functions* list, expecting a pathname to be\r
469 returned.\r
471 If a suitable file exists, it is loaded if\r
473 - there is no system of that name in memory, \r
474 - the file's last-modified time exceeds the last-modified time of the\r
475   system in memory\r
477 When system definitions are loaded from .asd files, a new scratch\r
478 package is created for them to load into, so that different systems do\r
479 not overwrite each others operations.  The user may also wish to (and\r
480 is recommended to) include defpackage and in-package forms in his\r
481 system definition files, however, so that they can be loaded manually\r
482 if need be.  It is not recommended to use the CL-USER package for this\r
483 purpose, as definitions made in this package will affect the parsing\r
484 of asdf systems.\r
486 For convenience in the normal case, and for backward compatibility\r
487 with the spirit of mk-defsystem, the default contents of\r
488 *system-definition-search-functions* is a function called\r
489 sysdef-central-registry-search.  This looks in each of the directories\r
490 given by evaluating members of *central-registry*, for a file whose\r
491 name is the name of the system and whose type is "asd".  The first\r
492 such file is returned, whether or not it turns out to actually define\r
493 the appropriate system\r
497 ** Syntax\r
499 Systems can always be constructed programmatically by instantiating\r
500 components using make-instance.  For most purposes, however, it is\r
501 likely that people will want a static defystem form. \r
503 asdf is based around the principle that components should not have to\r
504 know defsystem syntax.  That is, the initargs that a component accepts\r
505 are not necessarily related to the defsystem form which creates it.\r
507 A defsystem parser must implement a `defsystem' macro, which can\r
508 be named for compatibility with whatever other system definition\r
509 utility is being emulated.  It should instantiate components in\r
510 accordance with whatever language it accepts, and register the topmost\r
511 component using REGISTER-SYSTEM\r
513 *** Native syntax\r
515 The native syntax is inspired by mk-defsystem, to the extent that it\r
516 should be possible to take most straightforward mk- system definitions\r
517 and run them with only light editing.  For my convenience, this turns\r
518 out to be basically the same as the initargs to the various\r
519 components, with a few extensions for convenience\r
520                \r
521 system-definition := ( defsystem system-designator {option}* )\r
523 option := :components component-list\r
524         | :pathname pathname\r
525         | :default-component-class\r
526         | :perform method-form \r
527         | :explain method-form\r
528         | :output-files  method-form\r
529         | :operation-done-p method-form\r
530         | :depends-on ( {simple-component-name}* ) \r
531         | :serial [ t | nil ]\r
532         | :in-order-to ( {dependency}+ )\r
534 component-list := ( {component-def}* )\r
535                 \r
536 component-def  := simple-component-name\r
537                 | ( component-type name {option}* )\r
539 component-type := :module | :file | :system | other-component-type\r
541 dependency := (dependent-op {requirement}+)\r
542 requirement := (required-op {required-component}+)\r
543              | (feature feature-name)\r
544 dependent-op := operation-name\r
545 required-op := operation-name | feature\r
547 For example\r
549 (defsystem "foo"\r
550   :version "1.0"\r
551   :components ((:module "foo" :components ((:file "bar") (:file"baz") \r
552                                            (:file "quux"))\r
553                 :perform (compile-op :after (op c)\r
554                           (do-something c))\r
555                 :explain (compile-op :after (op c)\r
556                           (explain-something c)))\r
557                (:file "blah")))\r
560 The method-form tokens need explaining: esentially, \r
562                 :perform (compile-op :after (op c)\r
563                           (do-something c))\r
564                 :explain (compile-op :after (op c)\r
565                           (explain-something c)))\r
566 has the effect of\r
568 (defmethod perform :after ((op compile-op) (c (eql ...)))\r
569            (do-something c))\r
570 (defmethod explain :after ((op compile-op) (c (eql ...)))\r
571            (explain-something c))\r
573 where ... is the component in question; note that although this also\r
574 supports :before methods, they may not do what you want them to - a\r
575 :before method on perform ((op compile-op) (c (eql ...)))  will run\r
576 after all the dependencies and sub-components have been processed, but\r
577 before the component in question has been compiled.\r
579 **** Serial dependencies\r
581 If the `:serial t' option is specified for a module, asdf will add\r
582 dependencies for each each child component, on all the children\r
583 textually preceding it.  This is done as if by :depends-on\r
585 :components ((:file "a") (:file "b") (:file "c"))\r
586 :serial t\r
588 is equivalent to\r
589 :components ((:file "a") \r
590              (:file "b" :depends-on ("a"))\r
591              (:file "c" :depends-on ("a" "b")))\r
595 have all the \r
597 **** Source location\r
599 The :pathname option is optional in all cases for native-syntax\r
600 systems, and in the usual case the user is recommended not to supply\r
601 it.  If it is not supplied for the top-level form, defsystem will set\r
602 it from\r
604 - The host/device/directory parts of *load-truename*, if it is bound\r
605 - *default-pathname-defaults*, otherwise\r
607 If a system is being redefined, the top-level pathname will be \r
609 - changed, if explicitly supplied or obtained from *load-truename*\r
610 - changed if it had previously been set from *default-pathname-defaults*\r
611 - left as before, if it had previously been set from *load-truename*\r
612   and *load-truename* is not now bound\r
614 These rules are designed so that (i) find-system will load a system\r
615 from disk and have its pathname default to the right place, (ii)\r
616 this pathname information will not be overwritten with\r
617 *default-pathname-defaults* (which could be somewhere else altogether)\r
618 if the user loads up the .asd file into his editor and\r
619 interactively re-evaluates that form\r
621  * Error handling\r
623 It is an error to define a system incorrectly: an implementation may\r
624 detect this and signal a generalised instance of\r
625 SYSTEM-DEFINITION-ERROR.\r
627 Operations may go wrong (for example when source files contain\r
628 errors).  These are signalled using generalised instances of\r
629 OPERATION-ERROR, with condition readers ERROR-COMPONENT and\r
630 ERROR-OPERATION for the component and operation which erred.\r
632 * Compilation error and warning handling\r
634 ASDF checks for warnings and errors when a file is compiled. The\r
635 variables *compile-file-warnings-behaviour* and\r
636 *compile-file-errors-behavior* controls the handling of any such\r
637 events. The valid values for these variables are :error, :warn, and\r
638 :ignore.\r
640 ----------------------------------------------------------\r
641                       TODO List\r
642 ----------------------------------------------------------\r
644 * Outstanding spec questions, things to add\r
646 ** packaging systems\r
648 *** manual page component?\r
650 ** style guide for .asd files\r
652 You should either use keywords or be careful with the package that you\r
653 evaluate defsystem forms in.  Otherwise (defsystem partition ...)\r
654 being read in the cl-user package will intern a cl-user:partition\r
655 symbol, which will then collide with the partition:partition symbol.\r
657 Actually there's a hairier packages problem to think about too.\r
658 in-order-to is not a keyword: if you read defsystem forms in a package\r
659 that doesn't use ASDF, odd things might happen\r
661 ** extending defsystem with new options\r
663 You might not want to write a whole parser, but just to add options to\r
664 the existing syntax.  Reinstate parse-option or something akin\r
666 ** document all the error classes\r
668 ** what to do with compile-file failure\r
670 Should check the primary return value from compile-file and see if\r
671 that gets us any closer to a sensible error handling strategy\r
673 ** foreign files\r
675 lift unix-dso stuff from db-sockets\r
677 ** Diagnostics\r
679 A "dry run" of an operation can be made with the following form:\r
681 (traverse (make-instance '<operation-name>)\r
682           (find-system <system-name>)\r
683           'explain)\r
685 This uses unexported symbols.  What would be a nice interface for this\r
686 functionality?\r
688 ** patches\r
690 Sometimes one wants to \r
693 * missing bits in implementation\r
695 ** all of the above\r
696 ** reuse the same scratch package whenever a system is reloaded from disk\r
697 ** rules for system pathname defaulting are not yet implemented properly\r
698 ** proclamations probably aren't\r
699 ** when a system is reloaded with fewer components than it previously\r
700    had, odd things happen\r
702 we should do something inventive when processing a defsystem form,\r
703 like take the list of kids and setf the slot to nil, then transfer\r
704 children from old to new list as they're found\r
706 **  traverse may become a normal function\r
708 If you're defining methods on traverse,  speak up.\r
711 ** a lot of load-op methods can be rewritten to use input-files\r
713 so should be.\r
716 ** (stuff that might happen later)\r
718 *** david lichteblau's patch for symlink resolution?\r
720 *** Propagation of the :force option.  ``I notice that\r
722         (oos 'compile-op :araneida :force t)\r
724 also forces compilation of every other system the :araneida system\r
725 depends on.  This is rarely useful to me; usually, when I want to force\r
726 recompilation of something more than a single source file, I want to\r
727 recompile only one system.  So it would be more useful to have\r
728 make-sub-operation refuse to propagate ":force t" to other systems, and\r
729 propagate only something like ":force :recursively". ''\r
731 Ideally what we actually want is some kind of criterion that says\r
732 to which systems (and which operations) a :force switch will propagate.\r
734 The problem is perhaps that 'force' is a pretty meaningless concept.\r
735 How obvious is it that "load :force t" should force _compilation_?\r
736 But we don't really have the right dependency setup for the user to\r
737 compile :force t and expect it to work (files will not be loaded after\r
738 compilation, so the compile environment for subsequent files will be\r
739 emptier than it needs to be)\r
741 What does the user actually want to do when he forces?  Usually, for\r
742 me, update for use with a new version of the lisp compiler.  Perhaps\r
743 for recovery when he suspects that something has gone wrong.  Or else\r
744 when he's changed compilation options or configuration in some way\r
745 that's not reflected in the dependency graph.\r
747 Other possible interface: have a 'revert' function akin to 'make clean'\r
749   (asdf:revert 'asdf:compile-op 'araneida) \r
751 would delete any files produced by 'compile-op 'araneida.  Of course, it\r
752 wouldn't be able to do much about stuff in the image itself.\r
754 How would this work?\r
756 traverse\r
758 There's a difference between a module's dependencies (peers) and its\r
759 components (children).  Perhaps there's a similar difference in\r
760 operations?  For example, (load "use") depends-on (load "macros") is a\r
761 peer, whereas (load "use") depends-on (compile "use") is more of a\r
762 `subservient' relationship.\r