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