[asdf-devel] asdf output locations

Robert Goldman rpgoldman at sift.info
Mon Feb 1 15:06:40 UTC 2010


On 2/1/10 Feb 1 -2:53 AM, Faré wrote:
> Dear Tobias,
> 
> thanks for your feedback.
> 
....

>>  a) You should give short reason why backwards incompatibility is not
>>     provided. In particular, what the problems are with status quo.
> ""
> These previous programs' API was not designed
> for easy configuration by the end-user
> in an easy way with configuration files,
> and their previous API didn't fit the new paradigm.
> 
> But this incompatibility won't inconvenience many people.
> Indeed, few people use and customize these packages;
> these people are experts who can trivially adapt to the new configuration.
> Most people are not experts, could not properly configure these features
> (except inasmuch as the default configuration of
> common-lisp-controller and/or cl-launch
> might have been doing the right thing for some users),
> and yet will experience software that "just works",
> as configured by the system distributor, or by default.

For the record, I would like to say that this is most emphatically not
my experience.

At my firm, we have long used asdf-binary-locations, since we develop
software that runs on ACL, SBCL and may be branching out to CCL.

I /never/ configure ASDF-BINARY-LOCATIONS -- it interrogates my lisp and
computes a relative pathname like

allegro-8.1m-64bit-macosx-x86-64
sbcl-1.0.28-darwin-x86-64

All I do is:

(asdf:oos 'asdf:load-op :asdf-binary-locations)

and I value this highly.  I would not like to see this go away in favor
of an opportunity to indulge in further configurations, especially since
I am the de facto ASDF expert at my firm.

I would be interested to work with you to provide some equivalent
default behavior in the event of an otherwise-unconfigured ASDF Output
Locations (AOL --- there's a snappy name....), and I would prefer that
we not ship ASDF 2 without a similarly easy-to-use option.

best,
r




More information about the asdf-devel mailing list