asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

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

MAKE function documentation -- example of use?
by Robert Goldman 31 Jan '16

31 Jan '16

The make function description in the documentation is not described well. It seems to imply that there is a default operation for each system that the system developer can specify somehow, without saying how. I see that there's a FIXME suggesting that we need to document the BUILD-OPERATION option for DEFSYSTEM. It would be nice to have an example that shows how MAKE is intended to be used. Not a super-detailed example, just a quickie to show that this is not a feature in search of a use.... Anyone used this? thanks, r

2 2

newbie setup question
by Thomas Lynch 19 Jan '16

19 Jan '16

New at this, sure could use a pointer. I'm not able to get the code to build consistently. It works only after a failure. So I have to do it twice to get it to go. Sure would like to know what is wrong here. These are the directories: /home/LE/sbcl/LE.asd ;holds the definition, as shown below /home/LE/sbcl/src ;holds the lisp source files for my project The system is Debian, udpated today. quicklisp is installed. These are the commands I type: (require :asdf) (pushnew (truename ".") asdf:*central-registry* :test #'equal) (asdf:load-system :LE) (require :LE) (use-package 'LE) in a fresh environment this fails, and dumps me in the debugger, asdf:load-system tells me: "Component :LE not found: Then I exit the debugger, and run it a second time and it works. Not sure, may need quotes the first time, a colon the second, i.e. it is quirky. I have tried a lot of variations of the above, pretty much every example I've been able to find, some have "LE" instead of :LE everywhere. Here is the value of asdf:*central-registry* after the push: * asdf:*central-registry* (#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/") Here is the asdf file that is located in /home/LE/sbcl: (in-package :asdf-user) (defsystem #:LE :name "LE" :version "0.1" :author "Thomas W. Lynch <thomas.lynch(a)reasoningtechnology.com>" :description "Lynch's extensions" :depends-on ("local-time") ;; :serial t :components((:module "src" :components ( (:file "package") (:file "fundamental" :depends-on ("package")) (:file "test" :depends-on ("fundamental")) (:file "string" :depends-on ("test")) (:file "functions" :depends-on ("test")) (:file "list-0" :depends-on ("functions")) ;; (:file "list-L" :depends-on ("list-0")) ))))

4 6

Re: Intended behavior of *COMPILE-FILE-WARNINGS-BEHAVIOUR*
by Faré 15 Jan '16

15 Jan '16

[This was my reply that bounced yesterday. I edited it.] On 1/14/16 Jan 14 -1:20 PM, Robert Goldman wrote: > What is the intended behavior when this is bound to :IGNORE? > > I believe that if warnings occur, they should be quashed and > COMPILE-FILE should still return T, although otherwise it would not. > Yes, the intent is that in case of :IGNORE, the compilation should just succeed (assuming an output file was returned). > I'm finding a case where :IGNORE is not enough to make the compile-file > succeed, but I'm grappling with trying to find a minimal test case. So > I was wondering if I was interpreting this variable correctly. > Either no .fasl was created, or you found another bug in UIOP. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The uploaded man cut himself from the world. The optimizer saw the simulation would have no more side-effects and optimized it all away.

1 0

Re: Intended behavior of *COMPILE-FILE-WARNINGS-BEHAVIOUR*
by Robert Goldman 15 Jan '16

15 Jan '16

[... this message also bounced yesterday...] On 1/14/16 Jan 14 -1:20 PM, Robert Goldman wrote: > What is the intended behavior when this is bound to :IGNORE? > > I believe that if warnings occur, they should be quashed and > COMPILE-FILE should still return T, although otherwise it would not. > > I'm finding a case where :IGNORE is not enough to make the compile-file > succeed, but I'm grappling with trying to find a minimal test case. So > I was wondering if I was interpreting this variable correctly. > > thank you > The relevant bit of the manual describes acceptable values for this variable and COMPILE-FILE-FAILURE-BEHAVIOUR, but does not explain their semantics: ASDF checks for warnings and errors when a file is compiled. The variables *COMPILE-FILE-WARNINGS-BEHAVIOUR* and *COMPILE-FILE-FAILURE-BEHAVIOUR* control the handling of any such events. The valid values for these variables are ':error', ':warn', and ':ignore'.

1 0

Intended behavior of *COMPILE-FILE-WARNINGS-BEHAVIOUR*
by Robert Goldman 15 Jan '16

15 Jan '16

[This message bounced yesterday for some reason] What is the intended behavior when this is bound to :IGNORE? I believe that if warnings occur, they should be quashed and COMPILE-FILE should still return T, although otherwise it would not. I'm finding a case where :IGNORE is not enough to make the compile-file succeed, but I'm grappling with trying to find a minimal test case. So I was wondering if I was interpreting this variable correctly. thank you

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