[asdf-devel] asdf output locations

[Faré]

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".