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 _______________________________________________ Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel