- asdf-devel - mailman3.common-lisp.net

ASDF3: How to globally disable output translations on Windows
by 9nauuk 08 Mar '16

08 Mar '16

Hi, I just upgraded from SBCL 1.1.4 to SBCL 1.3.3. As a result, I I had to upgrade to ASDF3 from ASDF2. To make matters worse, I had to do this on a computer running Micros*t Windows (XP, to be exact.) I'd like to keep object files together with source files. With ASDF2, a 00-disable.conf file of a single line of (t t) in directory $HOME/.config/common-lisp/asdf-output-translations.conf.d/ would do the trick. I was surprised this does not work with ASDF3. After poking around for quite some time, I came across Section 13.5.2 at https://common-lisp.net/project/asdf/asdf.html. Adding a 99-disable-cache.conf file per the instruction at that section still won't make ASDF3 keep object files with my source files. I know I can call ASDF:DISABLE-OUTPUT-TRANSLATIONS in my .sbclrc but I also have a lot of Lisp code to be processed by SBCL invoked with "--no-sysinit --no-userinit". If you know how to wholly disable the compiler output cache on a Windows machine, I'll be grateful you can drop me a line. Best wishes, 9nauuk

4 3

Just tagged release candidate 3.1.6.16 with fix for bug 1533766
by Robert Goldman 07 Mar '16

07 Mar '16

This is the bug where a loop in the directory tree (typically introduced by a symbolic link) would cause the asd file search in initialize-source-registry to go into an infinite loop. I added a visited/closed list to this search. It relies on TRUENAME resolving symbolic links, so I can't guarantee it works everywhere. But I have tested on many implementations on Mac OS X. Will test on Linux and Windows as soon as my test machine is freed from work on an experiment (might be a couple of days). Cheers, r

1 0

Thoughts on CL-scripting
by Robert Goldman 29 Feb '16

29 Feb '16

Originally, I was very concerned to minimize the overhead of dependencies for building and testing ASDF, and I still think this is important. But I now conclude that trying to pull in the cl-scripting infrastructure was wrong, because it had the side effect of making the system used for testing be a dependency of the system under test, introducing unhealthy circularities. Going forward, if you want to experiment further along these lines, I'd suggest an entirely separate project -- with its own test suite! -- that would build an executable capable of executing CL scripts. That executable would have to NOT require bleeding-edge ASDF capabilities, only simple core capabilities. It should be built with the ASDF that's delivered with implementations, not with bleeding-edge ASDF. That executable could be built, saved, tested, and installed, and then could be used as the engine for ASDF building, testing, etc., if one liked. It could be a required build tool, the way today "make" is a required build tool. To be honest, I think such an engine should first be tested with much less demanding problems than building and testing ASDF. Simple scripting tasks, say within the ambit of the /Perl Cookbook/, would be a reasonable starting point. Even doing this, I think there's only a 50-50 chance the approach will work out. CL's numerous incapabilities where dealing with the host OS and filesystem will still stand in the way. Committing to a single implementation -- probably CCL or SBCL -- might solve this problem. A less cumbersome means of line-by-line processing of streams should be developed, and some means of using regexp literals should be added. Variable interpolation into strings should be provided. Just some thoughts.... Best, r

3 4

3.1.7 status
by Robert Goldman 29 Feb '16

29 Feb '16

the 3.1.7 release candidate now passes all tests on Mac and Linux, for me at least. The tests are not all passing for me on Windows, but I believe that this is not a problem with ASDF as such. Instead, it seems that when I run the make file from inside cygwin, the running lisp gets cygwin-style pathnames (e.g., /cygdrive/f/asdf/) instead of native-ish pathnames (f:/asdf/). I will have to modify the running environment to set an environment variable to indicate CYGWIN, and then decode the pathnames appropriately. Unfortunately, it seems that if we run cygwin and then use UIOP run-program inside it, we get cmd.exe, rather than cygwin bash, which makes it tricky for me to run cygpath to translate the pathnames. UIOP does not seem able to detect cygwin -- it has code that looks like uiop:os-unix-p should return t when cygwin is running, but that code seems not to work. It looks for a :CYGWIN feature which is not present, at least not under SBCL. I can see that uname -o returns "Cygwin", but can't run that from inside SBCL -- catch 22. Right now, I'm stumped by this. Going back to Real Work (tm) for the rest of the day.

3 4

test-sysdef-asdf failing
by Robert Goldman 27 Feb '16

27 Feb '16

This block of test is failing: (DBG "Load ASDF with proper configuration: should find asdf.asd from the source above") (initialize-source-registry `(:source-registry (:directory ,*asdf-directory*) (:directory ,*uiop-directory*) :ignore-inherited-configuration)) (clear-system "asdf") (load-system :asdf) ;; This time we found it, but it was skipped because the version was the same (assert-equal nil (system-source-file (find-system :asdf))) Can you explain why it's correct to have the SYSTEM-SOURCE-FILE of ASDF be NIL? I'm sorry, but I simply don't understand what you are testing here, or why the right answer is NIL. I think there's some critical fact about the system that you expect to hold after the immediately previous call to UPGRADE ASDF, but I don't know what it is. This is what's in the log file: While evaluating the form starting at line 48, column 0 of #P"/Users/rpg/lisp/asdf/test/test-sysdef-asdf.script": TEST ABORTED: These two expressions fail comparison with EQUAL: NIL evaluates to NIL (SYSTEM-SOURCE-FILE (FIND-SYSTEM :ASDF)) evaluates to #P"/Users/rpg/lisp/asdf/asdf.asd" Thanks, r

3 6

3.1.6.14 pushed: Surrender to minimakefile
by Robert Goldman 25 Feb '16

25 Feb '16

I give up on the "minimakefile' (the lisp scripting branch). I can't fight it any more. I have just put back "Makefile-classic" which will be how I do work on ASDF going forward. make -f Makefile-classic <command> should mostly work these days. If someone else wants to push the CL scripting build solution, that's fine with me, but I'm done. It's simply too rickety to have ASDF rely on itself to build itself, and CL is not ready for prime time as a scripting language. Now that this is done, I hope to be able to release 3.1.7 reasonably soon, assuming that I can recover the ability to test on Windows. I'm also having a little trouble with the clean-build tests... Cheers, r

1 0

Unable to run tests on Windows
by Robert Goldman 22 Feb '16

22 Feb '16

Now when I try to run the tests on Windows, I see: cmd /c make.bat l='' L='' u='' U='' v='' s='' t='' clean build\asdf-tools.exe was unexpected at this time. Makefile:65: recipe for target 'clean' failed make: *** [clean] Error 255 I'm not sure what's going on here. I believe in the past, I simply used the bash shell from cygwin. Now some check is made, and I am getting cmd.exe instead. At any rate, at this time, asdf-tools.exe does not exist. Could this be due to a change in inferior-shell? Or.... there's a comment about building an asdf-tools executable and that somehow it needs to be rebuilt after an update (?). The readme says I may have to make build-asdf-tools but when I try I get that same 'build\asdf-tools.exe was unexpected at this time.' error Have you been able to test this on Windows yourself? If not, we are going to have to revert out all of this stuff until we get ourselves to a state where ASDF builds again. I'm afraid that the 3.1.7 release has to be postponed until this can be straightened out.

1 0

What's the right way to extend ASDF with new symbols?
by Robert Goldman 16 Feb '16

16 Feb '16

Commonly, one wants to extend ASDF with new operation and component classes. But the support in ASDF for referencing such classes all involves automagically interpreting keyword symbols (and some unqualified symbols?) in the ASDF package. If I understand this correctly, this leaves the ASDF extender with the alternatives of either jamming their new symbols into the ASDF package late, and exporting them, or having them live in a new package, which is cleaner, but relegates these new components to second-class status. Consider the following (defpackage my-system-def (:use common-lisp asdf)) (in-package :my-system-def) (defsystem my-system :defsystem-depends-on ("my-asdf-extension") :components ((:my-new-file "file1"))) I don't seem to be able to define MY-NEW-FILE in my-asdf-extension and export it into my-system-def, because my-system-def is already defined by the time my-asdf-extension is loaded. That means I pretty much have to either muck around in the ASDF package (which doesn't scale to multiple different people extending ASDF) or use side effects: (asdf:load-system "my-asdf-extension") (defpackage my-system-def (:use common-lisp asdf my-asdf-extension)) (in-package :my-system-def) (defsystem my-system :components ((:my-new-file "file1"))) Am I right about this? If I am, is there some way to better handle this? Or do we need to rethink how :defsystem-depends-on works?

7 24

Warnings: towards 3.1.7
by Robert Goldman 15 Feb '16

15 Feb '16

I was having some trouble with warnings causing build failures in ASDF, despite (correctly?) setting variables. Please see the test-warnings branch on cl.net. This contains a small number of additional tests. I'll continue to look these over to see why they are failing. I'll move to release after these are fixed/dismissed as wrong. cheers, r

3 4

Time for 3.1.7 ?
by Faré 12 Feb '16

12 Feb '16

There have been many small fixes since ASDF 3.1.6 in last October, and I suppose it's time for a new minor release. Robert, do you want to handle the release? Are you done with it? What do you think? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Yesterday I was clever, so I wanted to change the world. Today I am wise, so I am changing myself. — Rumi (1207–1273)

3 6