Here is an old list of things to do, in addition to the bugs that are now tracked on launchpad: https://launchpad.net/asdf.
** packaging systems
*** manual page component?
** style guide for .asd files
You should either use keywords or be careful
with the package that you evaluate defsystem forms in.
(defsystem partition ...)
being read in the
will intern a
which will then collide with the
Actually there’s a hairier packages problem to think about too.
in-order-to is not a keyword:
if you read
defsystem forms in a package that doesn’t use ASDF,
odd things might happen.
** extending defsystem with new options
You might not want to write a whole parser,
but just to add options to the existing syntax.
parse-option or something akin.
A “dry run” of an operation can be made with the following form:
(let ((asdf::*verbose-out* *standard-output*)) (loop :for (op . comp) :in (asdf::traverse (make-instance '<operation-name> :force t) (asdf:find-system <system-name>)) :do (asdf:explain op comp)))
This uses unexported symbols. What would be a nice interface for this functionality?
** reuse the same scratch package whenever a system is reloaded from disk
Have a package ASDF-USER instead of all these temporary packages?
** proclamations probably aren’t
** A revert function
Other possible interface: have a “revert” function akin to
(asdf:revert 'asdf:compile-op 'araneida)
would delete any files produced by
Of course, it wouldn’t be able to do much about stuff in the image itself.
How would this work?
There’s a difference between a module’s dependencies (peers)
and its components (children).
Perhaps there’s a similar difference in operations?
(load "use") depends-on (load "macros") is a peer,
(load "use") depends-on (compile "use")
is more of a “subservient” relationship.