Faré wrote:
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.
So defsystem/ would contain asdf.asd, pointing to files in ../ and uiop.asd pointing to files in ../uiop/ ?
Or would we move the source files, as well?
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.
I promise not to do any big reorganization without extensive checking!
I think we can dodge this problem for a start, though. If one is doing the build process, and using the makefile, presumably one is sophisticated enough *not* to put the ASDF source tree into your default source registry. If you must do that, well, that's what the ASDF_DEVEL_SOURCE_REGISTRY is for: you must use it to specify for yourself a well-behaved source registry for development of ASDF.
[I think part of the reason this doesn't bother me (and part of the reason I haven't liked the conf.d approach to setting things up) is that I have *many* different source registry configurations, for different projects that use different libraries and even different versions of the same library. I have never had a single, universal Lisp development environment, and don't expect that I ever will.]
If we can dodge this for now, we can postpone dealing with it until we have closed out the current topic branches.
Cheers, r