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