asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Windows will no longer be supported by ASDF, or ASDF, Windows, Cygwin -- oh, my!
by Robert Goldman 21 Mar '16

21 Mar '16

I can set the configuration properly from an environment variable. But there are a number of tests that then reach out into the environment and try to reconfigure the source or otherwise read information. These are test-program.script test-try-refinding.script test-utilities.script None of these work properly when Lisp is running under cygwin. I'm inclined to think that this is an ASDF+Windows problem, and not a problem to be fixed in the tests. If you run a Lisp under cygwin, and you call some of these functions, they should simply error out, because the cygwin environment is going to give the lisp pathnames that it can't handle. Further, (a) we don't know how to call out to cygwin; (b) we can't call out to CMD.EXE when running under cygwin, because we have a polluted environment; and (c) UIOP cannot detect when it is running under cygwin. Under the circumstances, RUN-PROGRAM simply doesn't run reliably under cygwin. Worse, since we can't detect Cygwin, we really can't reliably run under windows at all, since we don't know when these functions will and won't work. This suggests the following: 1. We desperately need ASDF to be able to detect when it's running under cygwin, so it can at least error out when it's going to function wrong. 2. I don't know how to program make.bat. I will not be learning how to program make.bat. The test scripts that I can run are shell scripts. I have not been able to make Fare's lisp build and test scripts work and I am no longer trying to make them work at all, ever, anywhere. I don't believe they work any better under Cygwin, anyway. Ergo, if ASDF works on Windows, it will only be a matter of luck. Ergo, ASDF needs a windows tester and maintainer. I quite simply decline to perform this function. Someone who wants ASDF to work on Windows should step up. Unless someone steps up by the end of March, all further ASDF releases, starting with 3.1.7 will be officially Windows non-supporting. Windows patches and bug reports will be accepted. I will not make any attempt to fix Windows ASDF bugs myself. I will make only those Windows tests that I can make under Cygwin.

3 13

Windows tests
by Robert Goldman 20 Mar '16

20 Mar '16

I paused my experiments long enough to run the Windows experiments. The tests *mostly* work, except for test-sysdef-asdf which fails as follows: TEST ABORTED: Subprocess with command ("make.bat" "driver_files") exited with error code 1 AFAICT this just echoes a list of files that's hardcoded into make.bat: uiop\package.lisp + uiop\common-lisp.lisp + uiop\utility.lisp + uiop\os.lisp + uiop\pathname.lisp + uiop\filesystem.lisp + \ uiop\stream.lisp + uiop\image.lisp + uiop\run-program.lisp + uiop\lisp-build.lisp + uiop\configuration.lisp + uiop\backward-driver.lisp + u\ iop\driver.lisp So I don't see why we are running the subprocess instead of hard-coding the list of files into test-sysdef-asdf. The test claims to be testing that the makefile and .asd agree on the order of files, but it's not obvious how this happens. For now I'm simply disabling this test on windows, but if I can do something better than that, please LMK. Thanks, r

1 1

asdf version dependency
by Alexandre Rademaker 18 Mar '16

18 Mar '16

https://common-lisp.net/project/asdf/asdf.html#Version-specifiers So I can say that my system depends on a (:version :OTHER "x.y.z") which means a version >= x.y.z. Can I say explicit enforce a dependency of a particular version ? That is version equal of x.y.z instead of greater-than-or-equal x.y.z? Best, Alexandre Rademaker http://arademaker.github.com/

4 15

asdf 3.1.6.16
by Faré 10 Mar '16

10 Mar '16

While testing some unrelated piece of software, I fired up Genera on my new laptop and checked that asdf 3.1.6.16 works well enough to load fare-utils. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Whatever says the law, it is only ever forbidden but to get caught.

2 1

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

08 Mar '16

Hi, I'd like to thank Robert Goldman, Faré, and 73budden for replying to my message. Robert brought my attention to XDG-CONFIG-HOME in uiop.lisp. After taking a look at it and XDG-CONFIG-DIRS, I realized the following 3 directories (I don't think they would ever evaluate to NIL and (NIL NIL) on a Micros*t Windows machine): (get-folder-path :local-appdata) (mapcar 'get-folder-path '(:appdata :common-appdata)) would always take precedence over "config/", which means ASDF3 would never see $HOME/config/common-lisp/asdf-output-translations.conf.d/. The source code of XDG-CONFIG-DIRS also points out an easy way to globally disable output translations on Windows: Define an environment variable, XDG_CONFIG_DIRS, that points to whatever config directory you use. As a side note, on Windows, if (get-folder-path :local-appdata) is ever nil, and XDG_DATA_HOME is not defined, (xdg-data-home "config/") in XDG-CONFIG-HOME will explode in you face. > the filesystem. I believe "XDG" stands for "Easter Egg Hunt" in some > language.... Quite fitting. What happens to the good, old, dot-files (such as .emacs, .gnus, .cshrc, ...etc.)? Why this convoluted way? In both transitions from ASDF to ASDF2 and from ASDF2 to ASDF3, I had to spend time to make object files stay where I want them to stay. Loooooooong Live ASDF3! Best wishes, -9nauuk

2 1

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel