Next: Inspiration, Previous: FAQ, Up: Top [Contents][Index]
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.
Otherwise (defsystem partition ...)
being read in the cl-user
package
will intern a cl-user:partition
symbol,
which will then collide with the partition:partition
symbol.
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.
Reinstate parse-option
or something akin.
** document all the error classes
** what to do with compile-file failure
Should check the primary return value from compile-file and see if that gets us any closer to a sensible error handling strategy
** foreign files
lift unix-dso stuff from db-sockets
** Diagnostics
A “dry run” of an operation can be made with the following form:
(traverse (make-instance '<operation-name>) (find-system <system-name>) 'explain)
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
** proclamations probably aren’t
** when a system is reloaded with fewer components than it previously had, odd things happen
We should do something inventive when processing a defsystem
form,
like take the list of kids and setf
the slot to nil
,
then transfer children from old to new list as they’re found.
** (stuff that might happen later)
*** Propagation of the :force
option.
“I notice that
(asdf:compile-system :araneida :force t)
also forces compilation of every other system the :araneida
system depends on.
This is rarely useful to me;
usually, when I want to force recompilation of something more than a single source file,
I want to recompile only one system.
So it would be more useful to have make-sub-operation
refuse to propagate :force t
to other systems, and
propagate only something like :force :recursively
.
Ideally what we actually want is some kind of criterion that says
to which systems (and which operations) a :force
switch will propagate.
The problem is perhaps that “force” is a pretty meaningless concept.
How obvious is it that load :force t
should force compilation?
But we don’t really have the right dependency setup
for the user to compile :force t
and expect it to work
(files will not be loaded after compilation, so the compile
environment for subsequent files will be emptier than it needs to be)
What does the user actually want to do when he forces? Usually, for me, update for use with a new version of the Lisp compiler. Perhaps for recovery when he suspects that something has gone wrong. Or else when he’s changed compilation options or configuration in some way that’s not reflected in the dependency graph.
Other possible interface: have a “revert” function akin to make clean
.
(asdf:revert 'asdf:compile-op 'araneida)
would delete any files produced by (compile-system :araneida)
.
Of course, it wouldn’t be able to do much about stuff in the image itself.
How would this work?
traverse
There’s a difference between a module’s dependencies (peers)
and its components (children).
Perhaps there’s a similar difference in operations?
For example, (load "use") depends-on (load "macros")
is a peer,
whereas (load "use") depends-on (compile "use")
is more of a “subservient” relationship.
Next: Inspiration, Previous: FAQ, Up: Top [Contents][Index]