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

[asdf-devel] Patches against ASDF 2.26.5 for MKCL.
by Jean-Claude Beaudoin 03 Dec '12

03 Dec '12

Hello Faré, Here is a pair of tiny patches to update ASDF 2.26.5 for MKCL 1.1.2 (coming out RSN). The first one is against asdf itself. The second against asdf-bundle. Cheers, Jean-Claude

2 3

Re: [asdf-devel] Patches against ASDF 2.26.5 for MKCL. (bis)
by Jean-Claude Beaudoin 03 Dec '12

03 Dec '12

Here is the patch I mentioned. (oops!)

1 0

[asdf-devel] asdf-bundle and ECL
by Faré 30 Nov '12

30 Nov '12

> Found a problem: https://github.com/quicklisp/quicklisp-client/issues/68 OK, so Quicklisp was failing on older ECLs, because 1- it saw that older ECLs had an old ASDF, so it loaded its own more recent one (2.26) 2- when it loads a more recent ASDF, that invalidated the asdf-bundle part of ECL's ASDF. 3- when it further tried to (require :sockets), that failed, because require depends on asdf-bundle. Therefore, it looks like asdf-bundle is required when upgrading ASDF on ECL for Quicklisp. I bundled (pun intended) asdf-bundle into a single Lisp file asdf-bundle.lisp, so it's easier to deploy, either as part of ECL or of Quicklisp. Along the way, I fixed it for SBCL (some recent changes must have broken it), and tested it on SBCL and ECL: (asdf:load-system :asdf-bundle) (trace load) (asdf:operate asdf:load-fasl-op :fare-utils) Does what I expect from a fresh Lisp image where the fasls have been compiled already. Now, do we want to distribute asdf-bundle.lisp as a separate system asdf-bundle.asd? Do we want to distribute it as part of asdf.asd the way we used to do asdf-ecl.lisp? Do we want to just add its contents to asdf.lisp, a growth of a bit over 10% in size, for additional functionality on many platforms and much less headaches on ECL? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org An anarchist is a man who is careful to always use pedestrian crossings, because he utterly detests talking with policemen. — Georges Brassens

2 2

[asdf-devel] Patch with ABCL specific changes
by Mark Evenson 29 Nov '12

29 Nov '12

Attached please find a patch synchronizing the version of ASDF we intend to ship with abcl-1.1.0 with the canonical version. These changes deal with bugs when using systems contained in jar archives via the ABCL implementation specific extension of CL:PATHNAME.

2 3

[asdf-devel] ASDF 2.26 in Quicklisp
by Faré 29 Nov '12

29 Nov '12

At Xach's suggestion, I wrote this article on my livejournal about what has changed since Quicklisp's previous ASDF 2.014.6: http://bit.ly/WXJ8Kx —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?

7 19

[asdf-devel] ASDF-bundle and cross-compiling with ECL
by Sylvain Ageneau 28 Nov '12

28 Nov '12

Hello, I'm looking for input/suggestions about something I've been working on that is related to asdf-bundle. I'm trying to come up with a good solution to do cross-compiling of ASDF packages using ECL. For example I want to be able to create a bundle for a system that looks like this: (asdf:defsystem openglsample :components ((:file "package") #+cross (:file "shader-vao" :depends-on ("package"))) :depends-on (#+iphone iphone #+android android #+android cl+j #+(or android iphone) cl-opengl)) Using this system definition, I'd like to be able to create monolithic bundles libopenglsample_iphone.a and libopenglsample_android.a with the constraint that the android version will include the "android" and cl+j systems and the iPhone version will contain the "iphone" system. I tried adding new operations to asdf "cross-compile-op" "cross-lib-op" see here: https://github.com/ageneau/ecl-android/tree/master/lisp-packages/asdf-cross. This mostly works but the handling of the different *features* for each target is a bit of a mess since the host and the target can have different system definitions. Also because of side-effects, cross-compiling of a particular source file might depend on the host having loaded some dependencies first except the host will load this dependency with *features* that might be different than the target. I'm wondering would this be better suited for xcvb? In particular can xcvb cross-compile a system without the host doing the cross-compilation having to load the system definition for the system it is compiling? Regards, Sylvain

2 1

[asdf-devel] Fwd: asdf 2.26 released
by Faré 02 Nov '12

02 Nov '12

Dear Lisp hackers, I am pleased to announce the release of ASDF 2.26. Since previous release 2.25, the changes are as follow: Portability: * Lispworks: enable sys:get-folder-path on Personal Edition for Windows. * ECL: add proper wrapping-source-registry -- very important. Other: * Package change: removed the old ASDF-UTILITIES package nickname for ASDF. Please use the separate ASDF-UTILS system and package for utilities. * compile-file-pathname* bug fix for :output-file nil. Fixes lp#1067617. * get-folder-path factored out of various functions, thanks to Martin Simmons for the suggestion: at long last a change that REDUCES the amount of code in ASDF! As usual, developers, please test and enjoy, vendors, please update your implementation or distribution. (And yes, it would be nice if Quicklisp updated its ASDF at least once a year) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You think that by not releasing your in-house software, you save engineering resources. You only get yourself out of the loop.

2 1

[asdf-devel] ASDF breaks ECL's use of :PATHNAME
by Juan Jose Garcia-Ripoll 28 Oct '12

28 Oct '12

Currently, ASDF ignores all file types supplied by the user when specifying a :PATHNAME value for a component. This did not happen before, though. This is kind of annoying and hard to deal with, due to ECL's need of prebuilt ASDF files -- these are ASDF components that contain files with precompile sources, whose file extension need not coincide with the one being used by ASDF at the time. For instance, ECL may be launched with the bytecodes compiler as default (file extension is ".fasc"), but require to load sockets.asd, which contains the precompiled binary file sockets.fas, as in (DEFSYSTEM "sockets" :CLASS ASDF::PREBUILT-SYSTEM :LIB #P"SYS:LIBSOCKETS.A" :DEPENDS-ON NIL :COMPONENTS ((:COMPILED-FILE "sockets" :PATHNAME #P"SYS:SOCKETS.FAS"))) What would be the appropriate fix for this? Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 4

[asdf-devel] asdf and quicklisp
by Faré 12 Oct '12

12 Oct '12

Dear Zach, I'm a bit concerned about quicklisp shipping with a very old version of ASDF. Quicklisp says it depends on ASDF 2.011 or later in its *required-asdf-version*, but then you ship with 2.014.6 to load if the implementation's ASDF is too old. Both 2.011 and 2.014.6 are antique by ASDF standards, and what more, being older than 2.015, have trouble with self-upgrade as part of loading other systems that depend on ASDF. Actually, the good version for self-upgrade is 2.014.8, but I'm rounding to the next stable release; which brings me to my next point: 2.014.6 is not just old, but it's not a supported release version (not that all release versions are stable; 2.015 had many issues; but the supported answer is always to upgrade to the next stable release). What is the policy for upgrading the ASDF in Quicklisp? If it's not "never, ever", is it possible to upgrade your ASDF to something more recent? For instance, quicklisp contains asdf-encodings and xcvb which depend on asdf 2.21 for its :encoding feature, and asdf-finalizers which depends on asdf 2.23 for its :compile-check feature. Even without speaking of features, numerous implementation-specific fixes were committed since 2.014.6, and new implementations are supported. Why, of all CL software, is ASDF the only one never to be updated with Quicklisp? Is there anything I can do to make things more comfortable for you with respect to upgrading ASDF? PS: I otherwise think your work with Quicklisp is wonderful. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The penalty for laughing in a courtroom is six months in jail; if it were not for this penalty, the jury would never hear the evidence. — H. L. Mencken

3 7

[asdf-devel] asdf 2.25 released
by Faré 06 Oct '12

06 Oct '12

Dear Lisp hackers, I am pleased to announce the release of ASDF 2.25. Since previous release 2.24, the changes are as follow: Portability: * Lispworks: avoid professional edition functions in personal edition. * CormanLisp: improve support a little bit. * Exports: don't export utilities anymore. Please use asdf-utils. Internals: * We stopped exporting the utilities from asdf itself. We recommend you use asdf-utils to access the utilities in asdf. To avoid conflicts between alexandria, fare-utils, xcvb-driver, asdf-utils, etc., you can use xcvb-utils that solves the conflicts. Or you can use fare-utils:define-package-mix that will help you automatically resolve them. As usual, developers, please test and enjoy, vendors, please update your implementation or distribution. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The secret of survival is: Always expect the unexpected. — Dr. Who

2 1