[asdf-devel] ASDF 2.0 and beyond.

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sat Apr 17 23:30:38 UTC 2010


On Sun, Apr 18, 2010 at 12:20 AM, Faré <fahree at gmail.com> wrote:

> Juanjo and janderson both have had very good ideas, although in both
> cases, I think that there's a gap from the good idea to something that
> can be released as part of the build tool that everyone will use.
> Maybe we should start alternative branches on the git tree?
>

I do not think the gap is that large. As far as I am concerned all I care in
the very near future is making ASDF systems plain declarative, removing all
side effects from system files and leaving an architecture in which it is
possible to identify the components of a lisp library / program / fasl /
whatever and produce the binaries that ECL needs.

A slight polishing of the changes I have been submitting would cover all
that, because it fixes close to 100% of the situations in which side effects
are used:

* Defining test operations -> :test extension
* Manually loading systems that introduce new ASDF features ->
:asdf-dependencies
* Defining additional components -> can live now in files inside
:asdf-dependencies
* Defining packages for dependencies in the DEFSYSTEM form itself -> can be
solved by adding strings as possible tokens in a defsystem and using them
when parsing.
* Providing at least one logical pathname per system.

Besides this, there would remain just one detail which is packing the
combination of TRAVERSE + LOAD-SOURCE-OP + forcing everything into an API
function that can be used by other tools.

I believe this all can be in a 2.1 without great controversy. Actually,
given the size of the changes and their relative innocence, I think they
could have been in 2.0.

The only thing that might require some thinking is whether there is a better
way to take care of the problem with package names: tokens in the DEFSYSTEM
form living in other packages, as when people use cffi:grovel whatever
extensions, etc, etc.

Anything beyond this would belong to motivations that have appeared in later
discussion here and elsewhere

* Eventually replacing TRAVERSE with other alternatives (james anderson's?)
* Combined FASLs and dumping of executables
* A set of tools or rules for installing / uninstalling / distributing
binaries.
* Eventually phasing out the use of CLOS for extensibility, replacing it
with a declarative language in the asd file itself.
* In particular, regarding the previous point, per-component rules, much
like in Makefiles -- using a dictionary of rules and patterns instead of
ugly EQL-specializers that live beyond changes in our systems.
* Support for scripting and distributing of autoconf-like configuration
tools, that help people in integrating this software with distributions.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100418/fb4aab5e/attachment.html>


More information about the asdf-devel mailing list