On Fri, 2 Sep 2011, Robert Goldman wrote:
On 9/2/11 Sep 2 -12:25 PM, dherring@tentpost.com wrote:
[Indeed, Faré and I had in the past discussed the possibility that when a new system definition for an existing system is loaded, we should simply regard the entire system as "dirty" and always rebuild everything in it.]
...
In a serial CL process (all files loaded/compiled by the same image), the presence or absence of a file may greatly affect all files visited after it. Thus given this interactive image model, I don't think any simple option will work in all cases. The current behavior is reasonable (modulo where the files are found).
I fundamentally disagree about this. For two reasons:
- Correctness over convenience: It is more important to restore
...
- The model is fundamentally busted. If you reload a system file, the
data structures in ASDF are in a deeply wrong state. The SYSTEM objects
...
Thus, I wouldn't force a rebuild when the system definition changes, but a rebuild might be deserved when the source location changes.
The bad behaviors are not limited to bad behaviors from location changes. If you change the membership of the system, but the system is in the same location, that can introduce corruption, as well.
I don't see a way to keep correctness here and maintain the current behavior.
I'll try rephrasing my point. Under the interactive image model, recompiling the whole system provides only slightly stronger guarantees than not. State changes since the initial compilation may adversely affect the recompile, and downstream systems also face unknown issues. Thus I wouldn't force a recompile unless there was reason to believe the source files had changed (ASDF's default behavior).
For example, consider the difficulty ASDF has in bootstrapping new versions of itself.
Now, if your argument is that ASDF's internal state is completely unreliable after a system change, and the cleanest way to fix it is the nuclear option, then that is a strong argument for recompiling everything in the project.
I agree with Fare that XCVB addresses some of these issues. Don't understand it enough to say by how much (still todo... sigh).
Later, Daniel
P.S. I tend to agree with the "recompile cycles are cheap" argument, but it would be nice to have an option for people to skip a full recompile caused by minor system definition changes. It would be very useful when doing minor tweaks on large systems.