[asdf-devel] Recompiling SBCL contribs

[Faré]

On Fri, Nov 1, 2013 at 8:46 PM, Zach Beane <xach at xach.com> wrote:
> I'll try to put together a small test case. In the meantime, here are my
> ultimate goals:
>
>   - Load internal (e.g. "ASDF") and special (e.g. SBCL contribs) systems
>     normally
>
>   - Strictly and explicitly map where all other systems are found, with
>     no fallback to the central registry, source registry, etc.
>
>   - Save all FASLs for non-internal, non-special systems in a fresh
>     directory of my choosing
>
> The idea is to isolate the system load and avoid introducing untracked
> implicit dependencies from outside sources.
>
Interesting: as I'm integrating our Lisp build into the Google
infrastructure, I find that I'm doing pretty much the same thing. The
build is driven by a program called blaze that is exactly what you'd
imagine if you were to design a massively scalable build system:
http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.html

We build and store single fasls for our blaze packages with the
equivalent of fasl-op or monolithic-fasl-op, after having loaded all
fasl's for the dependencies, and (if using asdf at all) registering
all the dependencies as preloaded. We configure empty source
registries except for the tree of the package being built, so ASDF
when we use it never looks for (or at) anything but the system at
hand. They are empty when deploying. If we were not building at all,
we could disable the central and source registries entirely by
removing them from the *system-definition-search-functions*. This
strategy works because blaze always knows in advance the dependencies
that a lisp process will load during build. If you want to let the
user dynamically choose which systems to load, you can "simply"
replace the search function by one that does what you want, or
register a directory in either registry that has a trivial .asd file
that loads the corresponding fasl, in the style of the binary-op
output.

Unhappily, my current work is all too tied to Google-specific
infrastructure and unlikely to be untangled enough to be opensourced
(unless someone publishes a blaze clone), but you get the idea.

Are you building binary distributions for the next version of quicklisp?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The kind of man who demands that government enforce his ideas is always
the kind whose ideas are idiotic.  — H. L. Mencken