>: dherring > In my opinion, a lot of the complexity in ASDF is caused by its conflation > of two separate goals: a "build system" and a "loader". > Actually, in my asdf3 article, which I invite you to review, I actually list that as an asset that ASDF has compared to C systems: by having the same component path at compile-time and runtime, you minimize a lot of the complexity that C software distribution systems have. C systems need to ensure coherency between .h files and .so files via a complex mix of technical and social rules, and umpteen different configuration managers (autoconf, gconf, kdeconfig, etc., etc.). C code needs to be installed twice, once as source, another time as libraries.
[Source] https://github.com/fare/asdf3-2013/blob/master/asdf3-2014.scrbl [HTML] http://fare.tunes.org/files/tmp/asdf/asdf3-2014.html [PDF] http://fare.tunes.org/files/tmp/asdf/asdf3-2014.pdf > This compatibility is allowed because the loader (dynamic linker in C speak, > class loader in Java) has a simple, well-defined protocol for telling it > where to find things, independent of the build system. Look at the linux > manpages for ld.so and ldconfig... > The CL_SOURCE_REGISTRY was used by XCVB as well as ASDF, so there. But admittedly there is only one codebase: I originally wrote the code for XCVB, ebzzry wrote an initial port to ASDF, I hacked the code a lot as part of ASDF, and XCVB is reusing most of the code directly from ASDF. cl-launch also uses the registry via ASDF, and can be passed options to override it. XCVB usually produces self-contained executables; cl-launch can produce either self-contained executables or scripts that rely on the source-registry. > If CL is to grow from a dev-centric ecosystem to have a large base of > "normal users", I think we need to start finding ways to enable better > long-term stability. Pre-tested, "binary" releases are exactly what an end > user wants. Applications need to "just work" and not break whenever a > dependency changes its API. > If a user installs libraries in ~/common-lisp/ or wherever that override system libraries, he probably means it. If a programmer really wants to not have his libraries overridden by users, he can either fixate the source-registry in his script, or dump a self-contained executable. I think ASDF is already good enough in this regard. > What does this mean for ASDF? > > Since many CL developers want features like load-time recompilation, the > simple static decoupling in C between link and load is not possible. A > richer interface is required. > > While deprecated, the CL PROVIDE and REQUIRE API is very close to ideal for > a loader. Obvious extensions include protocols for adding versioning > checks/negotiation, search paths, re-build hooks, something better than > *MODULES*, and implementation independent behavior. This API should be as > small as possible, truly abstracting the different activities, and allowing > multiple implementations to coexist. > They are not ideal at all; indeed, they work completely differently on each implementation (or sometimes not at all, e.g. in GCL). And there is no way to portably extend this API... and/or the closest thing there is to it is ASDF itself, which manages to hook itself into require on all seven maintained free software CL implementations. > Then tools like ASDF could produce "installs" that fit into this framework. > The core loader would still be integrated into each CL distro, but the build > tool, with its dependency tracking, source file searching, and other > features could be distributed separately, and multiple tools could coexist > in a single image. > I'm not sure what you mean that cl-launch doesn't do. Are you suggesting a shared "big image" with everything pre-loaded, and what more one that maintains a buildapp-like and extensible list of dispatched-entry main functions depending on what the image is invoked under? > Wherever possible, the simplest loader solution should be chosen, leaving > sysadmins and/or build tools to handle any "difficult" configuration (such > as hidden directories). For example, the loader could require that all > libraries be installed using some UUID or hash-based scheme in a common > location, and hooks inside these installs are used to activate fancy > builder-specific features. > ASDF has an extensible *system-definition-search-functions*, courtesy of the far-seeing Dan Barlow. You can certainly adapt it some way. Or you can preload systems and use the new *immutable-systems* feature to prevent reloading. > I apologize, what I just wrote looks way too complicated. For example, it > is possible that versioning, searching, rebuilding, and loading could be a > builder-specific behavior inside a single try-load function. However it > works out, I do believe that a simple decoupled API that breaks ASDF into a > simple, stable loader core and a more featureful, faster changing piece, > would be good for everyone in the long term. > > Loaders have a simpler required feature set than build systems. Loaders > just need to allow for a few types of search scoping (per system, per user, > and per program). Build systems require configuration, searching, > incremental rebuilds, installation, unit testing, etc. > I'm not sure at all what you mean, and what that would look like. ASDF is pretty minimal within constraints — certainly, the mission creep has certainly led to a tenfold size increase in size since the Dan Barlow days (only fivefold and a half since I took over), but I'll argue that extending the mission was justified. Being able to write a #!/usr/bin/cl script that doesn't have to be modified specially depending on the implementation used and local installation paths — that's worth it. Oh, and not having any of the many bugs in ASDF1. That said, if you want to release a "load-only" version of ASDF that just hooks into require, only does the loading part assuming fasl-op output, go ahead. That might be interesting. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org God is Dead — Nietzsche Nietzsche is Dead — God Nietzsche is God — The Dead
