[Asdf-devel] request for test: experimental-submodules branch

[Robert P. Goldman]

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