I saw that. This doesn't help when asdf is in the source-registry, though (which is the recommended way of having an asdf upgrade: "just" having its source in the source-registry, e.g. in ~/common-lisp/asdf/)
Hm. And we have to have the asdf *tree* in the source-registry instead of only having the asdf *directory* in there because of the separation of uiop.asd and asdf.asd.
Is there some reason we can't move uiop.asd up to a position next to asdf.asd?
That seems like a much more pleasant solution than restructuring the repo to make the test and asdf source directories siblings instead of child/parent.
The reason is to make it easier to package uiop in a separate tarball, as used by e.g. quicklisp.
If we didn't have to care for Windows, I'd have suggested a symlink in the top directory, or a link farm directory somewhere. But we do have to support Windows, don't we? What does git do with symlinks on Windows? Are .lnk files supported on all Windows implementations? Meh. Another trick might have been a trampoline uiop.asd that just calls (asdf::load-asd (subpathname *load-pathname* "uiop/uiop.asd")) or maybe just (load ...) since the context was already setup by whichever load-asd got us there (hopefully). Or we could play a game, with asdf-driver.asd being in the top directory and doing the load-asd trick, whereas uiop remains invisible by default. Sigh.
That said, we could also move the defsystem files to a defsystem/ subdirectory, making the systems siblings, and being happy that way. Sometimes I think I should have done that before I released asdf3. Only inertia made me not do it (when asdf was a single file, it didn't matter; when I split it into many files, they were in the same system; when it appeared that a large fraction of the code was a separate portability library, I left it in the same directory at first, just a different system; when I separately packaged it and renamed it uiop as prompted by Xach, I moved just uiop to a different directory but left the .asd at the same place, and the rest of the defsystem with it.)
If you're going to move files, merging branches will be "interesting". Best done by merging branches with pre-move master, then merging the move step, then merging what follows.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Dost thou love life? Then do not squander time, for that's the stuff life is made of. — Benjamin Franklin