Dear Tobias,
thanks for your feedback.
a) I don't particularly like the name Output Locations. I can understand that a different name is needed. "FASL Location", would probably be most intuitive to Lispers -- though it can be used for more stuff.
But there's is more than FASLs involved. For instance, SB-GROVEL and CFFI-GROVEL create intermediate C files, executable files, and generated Lisp files. Test operations could create test report files. Etc.
A compromise would be to call the chapter in the actual documentation, "ASDF Output (FASL) Locations."
What about "ASDF Output Locations (FASL, etc.)"?
b) The documentation should shortly reflect how this was, implicitly, done in the past, and to what problems it lead.
OK.
"Previously, asdf-binary-locations, common-lisp-controller, cl-launch, and possibly other hacks were being used to redirect where asdf stores fasls and other output files. These were hard to setup, as they required the user to insert configuration statements precisely at the right time between the point that these pieces of software were loaded and the point that ASDF was first actually used. With the new mechanism, users can maintain a global configuration file and not have to worry about loading an extension to ASDF, and enjoy all the benefits of this relocation mechanism, including any relocations managed by the operating system distribution."
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. ""
b) Let's say someone is using the old ASDF-Binary-Locations (the package as it was before the merge into ASDF proper), let's further say his implementation will upgrade to the new ASDF, and he will update to this new version of his implementation -- will the old ABL package break under his feet? Silently fail?
Depends. I think that the way I'm going to do things, if he (or someone else form him) configures only one of these mechanisms, only that mechanism will be used. But if he configures both, "interesting" conflicts may happen.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Faré's Second Law of Dissent: I am Right, whence it follows that all who disagree with me are either (1) evil, (2) stupid or (3) crazy. (The alternatives are not mutually exclusive.) This universal law is valid for all values of "me", including "you".