asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

ASDF 3.1.7 has been released
by Robert P. Goldman 24 Mar '16

24 Mar '16

ASDF 3.1.7 is a bugfix release, enhancing the 3.1.x ASDF series. To the best of our knowledge, it only fixes bugs, and should thus be a low-risk upgrade for inclusion in implementations. Thanks, as ever, to Faré for many fixes, and to other bug reporters and patch-suppliers. See the Changelog (below) for a summary of changes. Bug fix and portability release: * Fix compilation on Genera. * Fix UIOP:FILE-EXISTS-P for dotfiles on CCL. * Fix infinite loop in source registry configuration that can occur when there are cycles in the filesystem (typically caused by symlinks) on some CL implementations. * Miscellaneous bug fixes. * Documentation improvements. * Restore original Makefile. -- Robert P. Goldman <rpgoldman(a)sift.net> Wed, 23 Mar 2016 09:34:14 -0500

2 1

Fw: cl-asdf debian package repo
by Kambiz Darabi 24 Mar '16

24 Mar '16

Dear all, now that a new ASDF release seems to be imminent, I would like to repeat my question from November 2015: can someone give me push access to the debian git repo for the package? The page https://alioth.debian.org/projects/pkg-common-lisp lists the following people as project admins: - Peter Van Eynde - Christoph Egger - François-René Rideau Thank you Kambiz -------------------- Start of forwarded message -------------------- From: Kambiz Darabi <darabi(a)m-creations.com> To: pkg-common-lisp-devel <pkg-common-lisp-devel(a)lists.alioth.debian.org> Cc: Robert Goldman <rpgoldman(a)sift.net>, Faré <fahree(a)gmail.com> Subject: cl-asdf debian package repo Date: Wed, 18 Nov 2015 10:28:52 +0100 Dear Debian Common Lisp Team, I would like to take over the packaging of cl-asdf with approval of the upstream maintainer Robert Goldman. The existing debian git repo [1] has been abandoned at some point in time and the debian/ subdir moved into the upstream repo [2]. We would like to separate the debian dir into its own repo again and the most natural place for it would be to go back to [1]. What would be needed to give me the necessary permissions to use that repo? Thank you Kambiz Darabi [1] git://git.debian.org/git/pkg-common-lisp/cl-asdf.git [2] https://gitlab.common-lisp.net/asdf/asdf -------------------- Start of forwarded message -------------------- From: Faré <fahree(a)gmail.com> Date: Tue, 17 Nov 2015 16:57:35 -0500 Subject: Re: ASDF 3.1.6 debian package To: Kambiz Darabi <darabi(a)m-creations.com> Cc: Robert Goldman <rpgoldman(a)sift.net> ... > Can you give me push permissions to > git://git.debian.org/git/pkg-common-lisp/cl-asdf.git or do I have to ask > on pkg-common-lisp(a)debian.org? > I do not have write access to this server. Please ask the pkg-common-lisp team, and/or get added to the team if you're not yet a member. (I was never officially a DM — are you?) -------------------- End of forwarded message -------------------- -------------------- End of forwarded message --------------------

2 6

Changelog for 3.1.7 pushed
by Robert Goldman 23 Mar '16

23 Mar '16

If anyone is willing to review, please do. Release later today, I hope. r

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel