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

Last call before 3.3.5 bug fix release
by Robert Goldman 29 Jun '21

29 Jun '21

I'm going to release 3.3.5, which I *hope* will be the last bug fix release in the 3.3 series, either this afternoon or tomorrow. So this is the last call for bug fixes that should get in under the wire. I have reviewed the issues and the merge requests, and I don't see anything that can't be postponed. There are still issues with ABCL failing test-around-compile.script and test-run-program-unix.script, but to the best of my knowledge those are waiting for bug-fixes in ABCL, rather than in ASDF. If a new ABCL comes out and these are still broken, we can have a 3.3.6 ... So, speak now or forever hold your peace! Thanks, R

1 0

(Lack of) Inheritance of in-order-to dependencies
by akater 21 Jun '21

21 Jun '21

I tried to specify a build-time dependency for ASDF system, and failed. The defsystem option :depends-on systems makes “systems” both build-time and runtime dependencies of a system being defined. I'm interested in specifying a dependency that is required at build time only. I attempted (defsystem "test-toplevel-in-order-deps" :in-order-to ((compile-op (load-op "some-macros"))) :components ((:file "a") (:file "b"))) but this way, some-macros is loaded too late: (let ((system (find-system "test-toplevel-in-order-deps"))) (plan-actions (make-plan 'sequential-plan 'compile-op system))) ;; => ((#<PREPARE-OP > . #<SYSTEM "test-toplevel-in-order-deps">) (#<PREPARE-OP > . #<CL-SOURCE-FILE "test-toplevel-in-order-deps" "a">) (#<COMPILE-OP > . #<CL-SOURCE-FILE "test-toplevel-in-order-deps" "a">) (#<PREPARE-OP > . #<CL-SOURCE-FILE "test-toplevel-in-order-deps" "b">) (#<COMPILE-OP > . #<CL-SOURCE-FILE "test-toplevel-in-order-deps" "b">) (#<PREPARE-OP > . #<SYSTEM "some-macros">) ... (#<LOAD-OP > . #<SYSTEM "some-macros">) (#<COMPILE-OP > . #<SYSTEM "test-toplevel-in-order-deps">)) I'm not requesting a feature but still, it's unfortunate that a seemingly basic task of specifying build-time dependency is unachievable in ASDF. My hypothesis is, if (compile-op . parent) depends on “actions”, then compiling children of parent should depend on “actions” as well, and similarly for all instances of downward-operation. I'm not sure what's the best way to implement this but I wonder if you find this reasonable in the first place.

2 1

Upcoming bug fix release
by Robert Goldman 06 Jun '21

06 Jun '21

I have just updated the ASDF repository to version 3.3.4.19 I plan for this to turn into the bug fix release 3.3.5 very soon, so please, if you have the opportunity, test it with your libraries, your hardware, your lisp implementations, etc. I am particularly excited to get this out there, because we have a number of enhancements on deck that could become version 3.4, and I would dearly like 3.3.5 to be the last bug fix release in the 3.3 series. Best, Robert

5 5

Very stupid question about :module.
by Marco Antoniotti 02 Jun '21

02 Jun '21

Hi I know I should RTFM, but the wisdom of real people is better. Plus, I am lazy... I would like to have a file depending on a "collection" of other files. I know I can use :module to do so, but how do I prevent the module from being cast into a directory? I.e., I have bar.lisp zot.lisp foobar.lisp I would like to say something like (:module "barzot" :components ((:file "bar") (:file "zot")) (:file "foobar" :depends-on ("barzot") How can I tell ASDF that there isn't any "barzot" folder? I know this must be a stupid question... Thanks Marco -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 http://cdac2021.lakecomoschool.org I-20126 Milan (MI) ITALY

2 2

ASDF components are brittle for backwards compatibility
by Robert Goldman 30 Apr '21

30 Apr '21

ASDF checks to make sure all of the initargs are defined when parsing a `defsystem`. This is good for catching errors, but is terrible for extensibility. This means that any attempt to add additional metadata will be backwards incompatible. I can think of two ways to fix this: 1. Add a "garbage can" slot to `component` that will be filled with a property list, and allow programmers to do whatever they want here. This doesn't seem great to me. 2. Add a new `defsystem` parsing error class that is `unknown-component-property`, raise it when an unknown property is encountered and allow the user to continue, discarding the initarg and accompanying value. The second alternative is what I favor. It isn't great, because it will only maintain extensibility going forward, but I think it's the best we can do. I suppose that we could also add an initarg to tell ASDF to continue such errors silently. I'd be inclined to suggest that this take an ASDF version expression as value, so that the error is quietly ignored only by ASDF versions below that. This means that the property will start to be checked when it has become authoritative. Note that for one's own `system` and `component` subclasses, the set of initargs can be extended without any monkeying around.

7 13

only perfom when the output is missing
by Attila Lendvai 18 Apr '21

18 Apr '21

dear hackers, i cannot convince ASDF to only perform my custom operation if the output file doesn't exist; i.e. regardless of the modification times. it's in cffi/c2ffi: foo.h -> foo.spec -> foo.lisp when the spec is there, regardless of the mod time, i'd like to skip the spec generation task. neither reading the manual, nor grepping around helped me to come up with the required magic. my custom operation-done-p isn't even called if the file's mod time instructs ASDF to run the operation. any hints are appreciated, including pointers to examples or tests. - attila PS: i sent the same mail from the wrong account, don't allow that through moderation please.

4 6

only perfom when output is missing
by Attila Lendvai 14 Apr '21

14 Apr '21

dear hackers, i cannot convince ASDF to only perform my custom operation if the output file doesn't exist; i.e. regardless of the modification times. it's in cffi/c2ffi: foo.h -> foo.spec -> foo.lisp when the spec is there, regardless of the mod time, i'd like to skip the spec generation task. neither reading the manual, nor grepping around helped me to come up with the required magic. my custom operation-done-p isn't even called if the file's mod time instructs ASDF to run the operation. any hints are appreciated, including pointers to examples or tests. - attila

1 0

[PATCH] Add a TEST-OP-TEST-FAILURE condition for test libraries to sub-class
by Vladimir Sedach 26 Mar '21

26 Mar '21

Hello! I recently wrote a script to run FiveAM tests for one of my libraries on many different implementations on your own machine: https://gitlab.common-lisp.net/uri-template/uri-template2/blob/master/run-t… It would be really nice if I did not have to copy-paste that script to my other libraries, and instead could contribute a generalized version to Roswell (on which the script is based) and have it work for any project using any test library. What I would like to be able to do, for any system: (handler-case (asdf:test-system "system") (asdf:test-op-test-failure (condition) (princ condition uiop:*stderr*) (uiop:quit 1))) The attached patch adds an ASDF:TEST-OP-TEST-FAILURE condition that test libraries can inherit from. I also added the necessary functionality to FiveAM: https://github.com/sionescu/fiveam/pull/58 It should be easy to add similar functionality to other testing libraries. This will make test automation trivial, with few, if any, changes required to systems that use ASDF and the testing libraries. One thing I would like to discuss is which condition ASDF:TEST-OP-TEST-FAILURE should inherit from. It definitely should not be ERROR - there is no error in test-op, or in running the tests; test failures are a regular and expected occurrence of running tests. Also problematic is widespread abuse of HANDLER-CASE to catch any ERROR; I am afraid if signaled from popular test libraries it would break someone's test running code somewhere. WARNING seems like a nice parent condition, but maybe having ASDF:TEST-OP-TEST-FAILURE inherit from CONDITION is a better idea. Thoughts? Vladimir

4 15

Dependency issue with program-op
by Didier Verna 22 Mar '21

22 Mar '21

Hello, I'm cross-posting because I don't know if the issue is related to ASDF or ECL. I'm using the most recent repos of both. When dumping a very simple system defined like this: (asdf:defsystem :simple :depends-on (:net.didierverna.clon) :components ((:file "simple")) :entry-point "simple:main") with (asdf:operate 'asdf:program-op :simple), I'm getting a runtime error with the executable: Condition of type: SIMPLE-PACKAGE-ERROR There exists no package with name "NET.DIDIERVERNA.CLON.SETUP" No restarts available. Top level in: #<process TOP-LEVEL 0x10a821f80>. So it seems that the net.didierverna.clon.setup system is not dumped in the executable. In Clon, the dependency on setup is indirect: net.didierverna.clon <- net.didierverna.clon.core net.didierverna.clon.core <- net.didierverna.clon.setup If I add an explicit dependency on setup in the :simple ASDF system above like this: :depends-on (:net.didierverna.clon.setup :net.didierverna.clon)) the problem goes away. This doesn't happen with the 5 other Lisp implementations that I've tested. Also, it may be worth mentioning that Clon's setup system gets a special treatment. It's loaded explicitly at the top of several .asd files like this (with the utmost disrespect for the Almighty ASDF Gods recommendations): (asdf:load-system :net.didierverna.clon.setup) I'm wondering if this may have something to do with the problem. Thanks! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

3 4

Pushed 3.3.4.11 and then 3.3.4.12
by Robert Goldman 21 Mar '21

21 Mar '21

The first has a fix for the incorrect argument handling in `launch-program`, and the second has two fixes for feature handling from Eric Timmons. At 4.12 it seems to me that we have a bunch of bug fixes that should be released into the wild, and there seems little cost to doing so, since there aren't breaking changes. So.... Please test out the current version if you can -- just download or clone it and use it in your day-to-day work, and report any issues. I plan to release ASDF 3.3.5 next weekend, assuming no one finds any real stinkers in the meantime, or if anyone has a high priority fix that needs to go in ASAP. Best, R

2 1