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?