[asdf-devel] Recompiling SBCL contribs
fahree at gmail.com
Thu Oct 31 21:59:42 UTC 2013
On Thu, Oct 31, 2013 at 5:32 PM, Zach Beane <xach at xach.com> wrote:
> Faré <fahree at gmail.com> writes:
>> On Thu, Oct 31, 2013 at 2:43 PM, Zach Beane <xach at xach.com> wrote:
>>> I've saved an executable SBCL image that includes asdf and calls
>>> load-system. If the system it's loading depends-on sbcl contribs,
>>> e.g. sb-bsd-sockets, it is recompiling the contrib sources.
>>> What causes contribs to get recompiled? Is there an easy way to inhibit
>> Which versions of SBCL and ASDF are you using?
>> Are you using some ASDF options such as enabling deferred-warnings?
> I am using SBCL 22.214.171.124+, and ASDF 3.0.3. I am initializing output
> translations with something like:
> (t "/path/to/fasls/")
Weird. Can you do the following:
(1) use (asdf:traverse 'asdf:load-op :your-system)
to identify the first few things that get recompiled
(2) use (asdf:input-files 'asdf:whichever-op '("sb-whatever" "component-name"))
and (asdf:output-files 'asdf:whichever-op '("sb-whatever" "component-name"))
to see what are the files involved, and
(3) use ls -l to check the timestamps of all said files
One thing that could have gone wrong is that somehow
during your SBCL installation, timestamps were not preserved,
and some .lisp file got a timestamp later than the corresponding .fasl.
Another thing that could have gone wrong is that somehow
your output-translations configuration fails to specially treat
the sbcl contribs.
Or then again, it could be a bug in ASDF that I missed because I've
been using for months the "no ASDF for contribs at runtime" patch
that was just included in the latest SBCL release. But I'm pretty sure
I faced that issue earlier and that it was working
when I released ASDF 2.27.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The major advances in civilization are processes that all but wreck the
societies in which they occur.
— A.N. Whitehead
More information about the asdf-devel