On 2010-02-02, at 23:54 , Robert Goldman wrote:
On 2/2/10 Feb 2 -4:13 PM, james anderson wrote:
On 2010-02-02, at 22:48 , Robert Goldman wrote:
On 2/2/10 Feb 2 -11:39 AM, james anderson wrote:
On 2010-02-02, at 18:17 , Faré wrote:
(c) Asdf binary locations / asdf output locations
ABL was already merged into ASDF by gwking. While I think it was a generally good move, it fails (b), and I think can and should be redone better.
then, once asdf is configurable, is there any reason to not take abl out of the core?
Can you explain what is meant, exactly, by "take abl out of the core"?
none of the respective functions or variables are defined if just asdf.lisp is loaded.
Why is this important? I can see that it /is/ important to you, but I don't follow why. [this is not intended as a snippy way of saying "this isn't important; it is a bona fide request for information.]
although i strive to be just an asdf user, there have been occasions when it didn't 'just work', whether because it was 'just plain broken' or incomplete. in which case its existence as open source made it possible for me to fix it - to wit simple patches which i submit on occasion, or to try to comprehend its workings and suggest ways to complete it - for example, the issue of dependency modes.
as occasional as this has been, it causes me concern when the amount of core code doubles without sufficient cause. especially as i continue to hold the belief, that it is possible to structure the additions such that they would be loaded on demand or by configuration only and otherwise not to be perceived should one need to examine its working.
in principle, it's really just a matter of general coding practice.
For that matter, I don't know what "configurable" means in this context. "Reads an init file"? It was always configurable in the sense that I could load my asdf:*central-registry*, and I developed several utilities for configuring ASDF using only this rudimentary facility.
I'm not sure I follow this. I certainly do /not/ want to see us revert to the days when asdf-binary-locations was a separate download.
if by 'separate download' you mean a separate file, why not? if your requirement is, that it be in the same tar package, that makes sense.
My requirement is that after loading asdf you should be able to do something equivalent to
(asdf:oos 'asdf:load-op :asdf-binary-locations)
or some similar thing like
(require 'asdf-binary-locations)
along the lines of my demonstration, one would reference the abl file in the asdf.asd for it to be included in the bootstrap.
and it should Just Work in the sense that A-B-L just worked --- it will tease apart binaries for different lisp implementations.
[It's more than OK with me that after that there should be some way to be more sophisticated about this, per Faré]
The reason I'm not necessarily agreeing with you is that "in the same tarball" doesn't necessarily entail "trivially loadable," although it might.
it should be possible to instruct asdf to include abl. just as to instruct asdf to leave abl out. which is different than to disable it.