wanted: don't recompile because of missing fasls

[Nathan Bird]

1. load-system :foo
2. save-lisp-and-die
3. delete fasls
4. start lisp with core from 2
5. load-system :foo

Currently: asdf will recompile the system because the output-files of the compile-op are missing.
Desired: no-op, the system is already loaded. If I wish to force recompilation, I will use :force, or would have asked it to perform asdf:compile-op.

I requested the system be loaded, I didn't request that fasls be on disk in a specific location.

asdf: 2.003
sbcl 1.0.40

[Nathan Bird (ecthellion)]

Diving further this is triggered because loading any system, unconditionally requires compiling the system.

My thoughts are that if all of the source files have a date that is older than the last load-op recorded for that component then it should be considered done.

[Faré (fahree)]

Not THAT simple.

Even if we wanted to short-circuit compilation when the code has already been loaded, we'd still have to recurse on dependencies to check that we don't need to re-compile and re-load. Currently, compile-op does all the recursing, and the dependency from load-op to compile-op is buried deep into the system.

It's probably fixable, but it's definitely not something I'd want to include in 2.0, though probably something worth it for 2.1. I won't do it, but patches are welcome, especially if you convince one of our automatic testers (Xach? janderson? dherring?) to try out your patch.

[Faré (fahree)]

It's not clear either what the use case is. You want to have a development system where some object files may have been deleted? That sounds strange. Why would anyone want that? Because of limited space on an embedded device?

A use case I find more convincing is delivery of fasls without corresponding source code, and images without corresponding fasl files. Then you may want to "seal" a system as never requiring further loading, by definition, or to distribute a single precompiled fasl as done experimentally by juanjo.

[Nathan Bird (ecthellion)]

The use case is as above: I've built a core and the fasls are now irrelevant-- the system shouldn't depend upon intermediate objects being in place.

The fasls aren't where lisp expects them because I build the cores and the rest of my development team uses them. The new output-translations layer places the fasls from my compilation in a private cache not visible to the other developers.

As a workaround I've configured output translations to have a shared cache (see the documentation error in https://bugs.launchpad.net/bugs/485918) so that the fasls are in the same place for all of us. Even with this it is finicky to the point I'm thinking of just dropping the core building as less reliable than the gain.

I did dig through the code enough to see that about the only logic for load-op was to depend upon compile-op so that it isn't going to be a trivial patch. Wishlist is fine, I just wanted it documented as it is a very non-intuitive behavior of the system.

[Faré (fahree)]

You are right about registering a bug - thank you.

As for a shared cache, the solution is that all the files that are precompiled should be in their own directory hierarchy, for which you define an output translation indeed (sorry for bug 485918). If you want to be super-correct, you use a #+feature to detect if you're using an implementation that has the precompiled fasls.

[Faré (fahree)]

Does the new precompiled-system feature solve your deployment problem?

[Faré (fahree)]

I believe release 2.27 offers a way to solve your problem, by defining precompiled systems, or otherwise using defsystem and/or register-preloaded-system.

Please re-open the bug if these solutions are not satisfactory.

[Faré (fahree)]

Actually, I believe the solution might involve a persistent default to :force-not, after it is made to override :force.

See https://bugs.launchpad.net/asdf/+bug/1184002