[asdf-devel] Is this necessary in this form? Re: ASDF 1.501
Tobias C. Rittweiler
tcr at freebits.de
Tue Feb 2 16:32:44 UTC 2010
james anderson writes:
> good morning;
Hi James!
> Are these additions necessary? In this form?
> I had wanted to propose a patch to one method and thought it
> appropriate to update before offering the diff for review.
> I now have 1.502 and observe, that `asdf.lisp`, which had 56,684 as
> of a version ca 2009-06-17 (it has a $Format version only), has grown
> through 87,098, to 98,665 through version 1.374 to 1.502. This is not
> a little.
>
> I understand that for some use-cases binary locations are thought to
> be indispensable.
> I have read the lauchpad bug descriptions and the livejournal essay,
> but remain unconvinced that the suggested additions are a good idea.
The livejournal essay was concerned about upgradability from earlier
versions of asdf to newer versions of asdf -- to make future development
practically possible.
What "suggested additions" are you refering to exactly?
(a) Upgradability
(b) Site and user configuration
(c) Asdf binary locations / asdf output locations
If I'm understanding correctly, Fare is mostly concerned about (a), and
(b) -- but wants to include (c) in to go.
> I offer for discussion an alternative[1], which
> appends to asdf.lisp an operator which bootstraps the system. Just
> because asdf system manipulation operators are insufficiently
> documented and inscrutable in their effects, does not mean they need
> be re-implemented in another model/namespace. There is also a patch
> to make absolute module locations work, because that is how I express
> my additions to the `asdf.asd` file, and one to (maybe) add mcl to
> the binary locations, but they are not central to this issue.
>
> The additions referenced in the `.asd` delta are also up there[2].
> One of them an extension to support hierarchical system names. The
> other implements contingent dependency. Their directory also includes
> mechanisms to generate and graph system definitions from a live
> image, but I'll need to prepare more stuff for public consumption
> before they're useful and - at least for the moment, they're limited
> to mcl/ccl.
>
> Your thoughts?
I have great trouble following the points you're raising. Could you give
them some more context -- especially for people who are not directly
involved in (and hence not closely following) development, but mere
users?
More information about the asdf-devel
mailing list