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? _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
