On Wed, 3 Feb 2010, Robert Goldman wrote:
"The best is the enemy of the good." --- Voltaire
So far, I have only written about pragmatically solved problems. Do you really want to hear what I think might be best? ;)
There seems to be a strong sentiment from at least part of this mailing list that ASDF loading should be reorganized so that some minimal core functionality is loaded, and more can be loaded on demand.
I'd like to go on record as opposing this. I see the arguments for tidiness involved, but I think there are some powerful arguments against doing this:
...
Compared to make or autotools or cmake or bjam or ... ASDF is very small in functionality, footprint, etc. Except for users having trouble finding docs, it is also rather easy to install.
Here's an approach that would make a lot of sense and solve numerous backward-compatibility issues. The full ASDF toolset may be big and hard to install [see below]. But a simple command drops a self-contained file customized for a particular system. Thus end users don't even have to install ASDF to use it!
This approach also solves the bootstrap issue -- users can bootstrap using the full functionality of ASDF. So it actually installs just like any other library.
- Daniel
P.S. Any similarity to the configure.ac -> configure transform is purely accidental. ;)