[asdf-devel] Is this necessary in this form? Re: ASDF 1.501

james anderson james.anderson at setf.de
Tue Feb 2 23:26:02 UTC 2010


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.





More information about the asdf-devel mailing list