Faré wrote:
Thanks. BTW, isn't my ROOT_DIR definition a good replacement for your sourceDirectory? I believe the latter could fail if the Makefile is invoked from another directory....
sourceDirectory is actually gwking's. Did five years already go by?
But to answer your question, make -C .../asdf/ will change the current directory, so taking the pwd is ok. Of course make -f .../asdf/Makefile from a different directory will do the wrong thing, but that's on purpose.
On purpose? Why? Is there some reason it's *wrong* for me to make the file robust to being invoked from a different directory?
I thought a reason to make this robust is in case someone grabs ASDF, puts it into a larger system (e.g., a lisp implementation), and does a make at a top level that invokes make in asdf....
But I'm not a make expert.
Actually, your command shows a challenge with using the full ASDF source tree: it exposes all the test systems.
That's a slight argument for stopping recursion at a directory containing a .asd and/or consulting a cl-source-registry.conf file: so you can have private .asd's that are only visible when you explicitly tweak your source-registry or central-registry, during tests or otherwise controlled builds.
I will fix this.
I'm not sure what you intend to do. Prefix all the system names with test-asdf or such? I admit that was one of the reasons for me to reduce the number of actual .asd files in our test directory: when possible, either use define-test-system in a .script, or use secondary systems of test-asdf.asd. But I didn't go through all existing files to fix them; I only made such changes as I was fixing other bugs.
Maybe ongoing cleanups like this ought to be documented in a TODO entry.
I did something much simpler: I enumerated the directories instead of just loading the whole tree. My current settting is:
export CL_SOURCE_REGISTRY = ${sourceDirectory}/:${sourceDirectory}/uiop/:${sourceDirectory}/ext//:
That gets only ASDF, UIOP, and the dependencies.
Cheers, r