asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Deferred warnings broken on SBCL 1.4.7
by Eric Timmons 30 May '18

30 May '18

Looks like SBCL 1.4.7 changed the slots of sb-c::compiler-error-context (in particular enclosing-source -> %enclosing-source, source -> %source, and original-source was removed). As a result, deferred warnings are broken. Attached is the output of `./run-tests.sh sbcl test-deferred-warnings.script` -Eric

3 8

Re: asdf-announce post from nimiux@gentoo.org requires approval
by Faré 05 May '18

05 May '18

Chema Alonso asked: > Where can I download the 3.3.2 tarball? > > Normally I get it from here: > > https://common-lisp.net/project/asdf/archives/ > > But I can't find it right now. > > Thanks. > I took the liberty of running "make archive publish-archive" from the release branch. The tarballs should now all be present. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The hacker: someone who figured things out and made something cool happen. — Alan Schmitt

1 0

ASDF 3.3.2 Released
by Robert Goldman 04 May '18

04 May '18

Today we release ASDF 3.3.2, the second bugfix release for the 3.3 release series. Of primary interest in this release are 1. Multiple fixes in handling misnamed (or "legacy-named," if you prefer) secondary systems ("foo-test" instead of "foo/test"). Thanks to Eric Timmons, there is also a similar fix for package-inferred-systems. 2. Fix an annoying warning message for compute-action-stamp. 3. Add support for the Mezzano implementation (thanks to E. Housel, H. Harrington). 4. Miscellaneous minor fixes and documentation tweaks. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.2 at their earliest convenience. Immense thanks, as always, to Fare Rideau. Also thanks to the many bug reporters and patch submitters (see the Changelog), and to Anton Vodonosov and Dave Cooper for help with testing. Here is the changelog entry for 3.3.2: cl-asdf (2:3.3.2-1) unstable; urgency=low Bug fix release: * Dependency tracking: fix bugs in handling misnamed secondary systems. We now distinguish between "syntactic" and "semantic" primariness, properly warn in case a secondary system is misnamed, yet properly recompile or avoid spurious recompilation depending on whether there or not is a conflict or redefinition. Similarly handle package-inferred-system (thanks to Eric Timmons). Better warning in a fishy case of compute-action-stamp. * UIOP: Add package location information to define-package on SBCL. * Upgrade: fix issue with asdf/bundle. * Portability: add support for Mezzano (thanks to E. Housel, H. Harrington) * Documentation: add discussion of best practices. * Package-inferred system: Improve source file handling. * Test and documentation improvements. -- Francois-Rene Rideau <fare(a)tunes.org> Thu, 03 May 2018 22:46:19 -0400

1 0

Testing for ASDF 3.3.2 and beyond?
by Faré 27 Apr '18

27 Apr '18

Dear Anton, can you run the below tests, in order or priority? 1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users. 2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also... 3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too. 4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only. The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3). https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-con… https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.

5 26

Problems with DEFSYSTEM-DEPENDS-ON
by Mark Evenson 09 Apr '18

09 Apr '18

The usage of DEFSYSTEM-DEPENDS-ON to specify dependencies that will be satisfied by QL:QUICKLOAD no longer seems to be working in asdf-3.3.1. It used to be the case that to use the [PROVE testing framework][1], it was sufficient to place a … :defsystem-depends-on (:prove-asdf) … clause in the secondary system to be tested, and then upon a QL:QUICKLOAD of this system, the dependency on PROVE was then resolved via a network download from Quicklisp. [1]: https://github.com/fukamachi/prove I believe this was working with asdf-3.2, but testing that assumption is a little hard as asdf-3.3 refuses to degrade itself with a downgrade, and all my systems are running asdf-3.3. Maybe something in Quicklisp changed as well?

5 11

Re: Building from clean on Allegro Windows
by Faré 09 Apr '18

09 Apr '18

I couldn't reproduce with AllegroExpress 10.1 on Linux amd64. So I gave a closer look on the Windows VM, rm'ing all the files in build/results/ before I retried, and looked at the minimal logs for the issue. The warnings were a false lead: Allegro does issue them, but they are actually caught by the build system, so were not the issue. The real issue was that allegro was looking for alisp.exe.dxl instead of alisp.dxl. I thus modified run-tests.sh so it will handle this case with more care. All the tests then passed except test-multiple (which works for me on Linux). Unsurprisingly, I see test-multiple uses ln -s and has an ugly workaround on Windows that doesn't work on sbcl, either. I moved it from using ln -s to using copies, which modified the behavior in ways I admit I don't fully comprehend. I documented the parts I did understand. test-multiple exercises a really dark corner of the design, anyway, one that we're trying to deprecate, badly-named secondary systems. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You may easily play a joke on a man who likes to argue — agree with him. — Edgar Waston Howe On Sat, Apr 7, 2018 at 3:22 PM, Robert Goldman <rpgoldman(a)sift.net> wrote: > Got the same issue: > > Warning: FIRST-FEATURE is defined more than once as `operator' in file > build\asdf.lisp. > Warning: IMPLEMENTATION-TYPE is defined more than once as `operator' in > file build\asdf.lisp. > Warning: *IMPLEMENTATION-TYPE* is defined more than once as `variable' > in file build\asdf.lisp. > Warning: OPERATING-SYSTEM is defined more than once as `operator' in > file build\asdf.lisp. > Warning: ARCHITECTURE is defined more than once as `operator' in file > build\asdf.lisp. > > I'll see if I can figure out what causes this. EVAL-WHEN is a likely > candidate. > > More as I have news, > r

2 1

Re: Issues with package location information on SBCL
by Eric Timmons 04 Apr '18

04 Apr '18

On Mon, Feb 19, 2018 at 7:03 PM, Eric Timmons <etimmons(a)mit.edu> wrote: > I've also opened the following bug on SBCL to let them know about it: > https://bugs.launchpad.net/sbcl/+bug/1750466. This bug has been fixed upstream and should probably appear in SBCL 1.4.7. Since they got that fixed before ASDF 3.3.2 got out, is it worth reverting commit 21e3a85? That would keep the return of `parse-define-package-form` unchanged and the warnings would only show up in SBCL 1.4.1-1.4.6 inclusive. -Eric

1 0

"deprecated recursive use" warning
by Attila Lendvai 01 Apr '18

01 Apr '18

dear list, shall i be concerned about this? WARNING: Deprecated recursive use of (ASDF/OPERATE:OPERATE 'ASDF/LISP-ACTION:LOAD-OP '("cffi/c2ffi-generator")) while visiting (CFFI/C2FFI::GENERATE-LISP-OP "hu.dwim.zlib" "c2ffi-spec" "zlib.h") - please use proper dependencies instead it happens due to this in cffi/src/c2ffi/asdf.lisp: (defmethod perform ((op generate-lisp-op) (c c2ffi-file)) ... (unless (component-loaded-p :cffi/c2ffi-generator) (load-system :cffi/c2ffi-generator)) ... ) that system only needs to get loaded when the action is executed. or is it safe to ignore that warning long term? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If we have the truth, it cannot be harmed by investigation. If we have not the truth, it ought to be harmed.” — J. Reuben Clark (1871–1961)

4 7

follow-up about handling .info file and index
by Robert Dodier 22 Mar '18

22 Mar '18

Hi, I was asking recently about how to handle a .info file and its index (CL) in ASDF. What I finally settled on is this. When the operation is COMPILE-OP, the .info file is copied to same location where the index fasl will go (because the index has some code to read the .info and it assumes the .info is in the same place as the fasl). In the .asd file, I say (defsystem-depends-on "info-index") and (:info-index "foo-index") for the component foo-index.lisp. This seems to be working as intended. I've pasted the code I devised as a PS below. If anyone has any comments about it, I would be interested to hear it. I have a couple of specific questions about the code, which you can see in the comments. (1) In the class definition for INFO-INDEX, it seems to be necessary to intone (type :initform "lisp"). Is that actually necessary? If so, why is that? I would have expected (on little reason) that the parent class CL-SOURCE-FILE would supply that. (2) In INPUT-FILES, why doesn't (info-index-type c) yield "lisp"? Doesn't INFO-INDEX have an accessor INFO-INDEX-TYPE? I may well be very confused about simple things. Thank you for your patience, I appreciate it. Robert Dodier PS. info-index.lisp: ;; info-index.lisp -- ASDF component type for Maxima documentation index ;; copyright 2018 by Robert Dodier ;; I release this work under terms of the GNU General Public License (require 'asdf) (in-package :asdf) (defclass info-index (cl-source-file) ((type :initform "lisp"))) ;; ISN'T THIS INHERITED FROM CL-SOURCE-FILE ?? (defmethod perform ((o load-source-op) (c info-index)) (call-next-method)) (defmethod perform ((o load-op) (c info-index)) (call-next-method)) (defmethod input-files ((o compile-op) (c info-index)) (let* ((foo (call-next-method)) ;; WHY DOESN'T THE FOLLOWING LINE WORK ?? ;; (bar (info-index-type c)) (bar "lisp") (baz (merge-pathnames (make-pathname :type bar) (first foo)))) (list baz))) (defmethod output-files ((o compile-op) (c info-index)) (call-next-method)) (defun silly-copy (in-file out-file) (unless (equalp in-file out-file) ;; silently refuse to copy file to itself (with-open-file (in in-file) (with-open-file (out out-file :direction :output :if-exists :supersede) (do ((c (read-char in nil) (read-char in nil))) ((null c)) (write-char c out)))))) (defmethod perform ((o compile-op) (c info-index)) (let* ((system-name (component-name (component-system c))) (info-name (make-pathname :name system-name :type "info")) (info-in-file (merge-pathnames info-name (first (input-files o c)))) (info-out-file (merge-pathnames info-name (first (output-files o c))))) (silly-copy info-in-file info-out-file) (call-next-method)))

3 5

using most recent .asd file, if multiple are present
by Robert Dodier 20 Mar '18

20 Mar '18

Hi, I wonder if it's possible that if multiple .asd's with the same name are present, I can ensure that the .asd with the most recent timestamp is used. The use case I have in mind is that I'm trying to set up a system to download automatically-generated tarballs which contain a snapshot of a project. Snapshots contain whatever was available (in Git) at the time the tarball is generated. These are unpacked (by Quicklisp) and all files in the tarball are given timestamps equal to the time at which the tarball was unpacked (not the time the tarball was generated and not the time of the most recent file modification or commit). Each tarball has a different name (derived from Git project name + most recent commit hash) so there will be multiple .asd files with the same name in different directories. But since they all have different time stamps, I think I'm in good shape: I just need to be able to identify the most recent one. I see the ASDF manual says: "When looking in a tree, if one system is found, the search succeeds. If multiple systems are found, the consequences are unspecified: the search may succeed with any of the found systems, or an error may be raised. ASDF currently returns the first system found, ...". Is there any way to intervene to return a specific system, specifically the most recent one? Thank you once again for your help, Robert Dodier

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel