Abstract: SBCL does not need to change --script for this issue. The main
problem is learning how to use ASDF 2, with some difficulty reliably
bootstrapping it.
On Tue, 12 Oct 2010, James Y Knight wrote:
> This is all starting to sound really complicated, and that seems unnecessary.
Agreed on that point. The proposed features were not sounding clear or
orthogonal.
> Let's take Python ... a standard set of paths: first, the contents of
> the PYTHONPATH environment variable. Then, the implementation-internal
> paths, systemwide paths, and user-specific paths. Those are not
> configurable with a config file, they're set as part of the
> installation.
>
> So, normally, users will either install packages in the site-wide
> location, or the user-specific location. And things will just work,
> without any configuration.
This is heavily inspired by the C loader system, a proven technology. I
suggest that everyone read `man ld.so` to see what customization points
it provides.
http://www.kernel.org/doc/man-pages/online/pages/man8/ld.so.8.html
Then there's the super-simple approach: what is so evil with embedding
paths into the script? Prior art: shebang lines, RPATH, crontabs
and classic CGI scripts, ...
Concluding points:
- There should be a mechanism for specifying library paths, independent of
the general "sbclrc" support. ASDF 2 provides this.
- There should be ways to specify more specific paths for a particular
user or script. ASDF 2 and in-script paths provide most/all of this[1].
- Sometimes a pig really is just a pig. There is no magic solution to
library paths, but common patterns keep appearing becuase they can handle
most cases nicely. Many of the exceptional cases really are asking too
much (such as over-the-shoulder, intuition-guided inconsistency).
- We do need a guaranteed way of having a "library loader" properly
configured when a "script"/"standalone app" starts. Since ASDF itself is
just a library, there is a potential bootstrapping issue here. That is
eased by getting some version of ASDF 2 baked in to all the impls[2].
- Its about time to start a "how to configure ASDF" thread on asdf-devel,
with guidelines on what goes where, when to use the different hooks, etc.
I'm not quite confident, but getting close.
Later,
Daniel
[1] Big thanks to Fare for implementing a better config mechanism for
ASDF, even though we're still not 100% sure how to use it. It seems that
SAVE-LISP-AND-DIE and fasl concatenation are the "static linking" options
for SBCL. There are a few remaining gaps.
- LD_PRELOAD and RTLD_NEXT
PRELOAD forces an exact library to be used. Think of NEXT as :around
for libraries. Great power tools.
- LD_TRACE_LOADED_OBJECTS, LD_DEBUG, and LD_VERBOSE
Its nice to have the loader say what its loading, from where, etc.
Maybe ASDF has stuff for this? Even when default streams are redirected?
- RPATH info embedded in libs
helps find dependencies in unusual places (esp. customized forms of
common libs)
[2] Is upgrading SBCL's ASDF contrib as simple as overwriting
lib/sbcl/asdf/asdf.fasl with a newer version? I was surprised that ASDF
did not add a safeguard to prevent an accidental downgrade of the library.
This complicates efforts of tools like quicklisp and libcl to "always
provide a current copy".
P.S. Bonus OT: The core feature should be a "library loader" with
semantics similar to ld.so or the much maligned, underspecified and
underimplemented REQUIRE. ASDF has too many features (pseudo-random
recompilation wrt discrete apps) and requires complete control of the
world (no easy way for "some loader file" to satisfy an ASDF dependency)
to be the universal foundation for CL loading.
|