OK, I have committed a first shot at fixing this.
However, there is no easy way to have a module update its components upon dependency change but not have a system update its components upon dependency change, because a system is a subclass of module.
So my path may not be desirable, or at any rate the community may want to think about it a bit before adopting it.
Furthermore, I did the patch as a minimal perturbation to TRAVERSE, which has a structure which I, at least, find somewhat difficult to follow. The structure is one large function with a FORCED variable which holds the plan (sequence of OP . COMPONENT pairs). This large function contains three sub-functions in LABELS that destructively modify the FORCED variable.
I think a good case could be made for breaking those sub-functions out (for easier tracing, if nothing else), and having them return values that are appended onto the list, instead of side-effecting.
But this is an aesthetic matter, and would also create many problems for understanding the modifications I made, so I did NOT do this.
Since these changes seem to me controversial, I did not push my changes into the main repository, but instead added a "module-depends" branch to the common-lisp.net git repository. I hope that this will make the changes easier to assess.
Cheers, r
Dear Robert,
However, there is no easy way to have a module update its components upon dependency change but not have a system update its components upon dependency change, because a system is a subclass of module.
thanks for your work and congratulations for fixing the bug!
So my path may not be desirable, or at any rate the community may want to think about it a bit before adopting it.
Personally, I think this was a bug in ASDF that is better fixed.
If anyone cares for the old behavior, they should request for a feature to do it properly. Something like an (oos 'assume-loaded :system :time (get-universal-time)) or (oos 'assume-loaded (list :system "module" "file")) or something.
But indeed, if a substantial number of people rely on the old behaviour, we have to support it. At ITA, where we have large systems, the old behaviour is just too broken for us to care for. It essentially means that incremental compilation of our large (>700 files) system fails more often than not.
Furthermore, I did the patch as a minimal perturbation to TRAVERSE, which has a structure which I, at least, find somewhat difficult to follow. The structure is one large function with a FORCED variable which holds the plan (sequence of OP . COMPONENT pairs). This large function contains three sub-functions in LABELS that destructively modify the FORCED variable.
I think a good case could be made for breaking those sub-functions out (for easier tracing, if nothing else), and having them return values that are appended onto the list, instead of side-effecting.
But this is an aesthetic matter, and would also create many problems for understanding the modifications I made, so I did NOT do this.
Thanks. I think you did the right thing.
I think we *should* refactor TRAVERSE, but it is better if the commit that does it is as semantics-preserving as possible.
Note that your first modification (a comment about what TRAVERSE fails to do) seems to be invalidated by your other modifications that fix the issue.
Since these changes seem to me controversial, I did not push my changes into the main repository, but instead added a "module-depends" branch to the common-lisp.net git repository. I hope that this will make the changes easier to assess.
I say you should wait a week for further comments, then merge your changes into trunk. When you're done merging and refactoring TRAVERSE, I would release ASDF 1.700 (or you can do it yourself if you feel bold).
Regards,
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] License Agreement: By reading this message, you agree to run around the room which you are currently in, flapping your arms, and squawking like a chicken.