Hi,
I have a few questions about controlling ASDF execution of compile/load
operations:
1. Suppose I have performed successful `load-op` on a certain system. After
some time and no changes to the source code of the system nor its
dependencies, I run `load-system` again on the same system. How can I
ensure that no compile/load action is performed?
2. Suppose I have a system `foo` that depends on `bar`. Now, I explicitly
call `(load-system :bar)`. How can I ensure that when I call `(load-…
[View More]system
:foo)` no compile/load action is performed on `bar`?
Sorry, maybe, these questions are trivial, but I couldn't find definite
answers in the docs.
---
Vsevolod Dyomkin
+38-096-111-41-56
skype, twitter: vseloved
[View Less]
Is it just me, or is the :FEATURE dependency-def form undocumented in
the manual? It is *mentioned* in the grammar, but I don't see it
documented -- except for the misleading mention that the :FEATURE
*requirement* has been removed from ASDF.
# This is used in :depends-on, as opposed to ``dependency,''
# which is used in :in-order-to
dependency-def := simple-component-name
| ( :feature FEATURE-EXPRESSION dependency-def )
| ( :version simple-component-name version-…
[View More]specifier )
| ( :require module-name )
I'm actually not sure what the semantics of this should be:
1. if the FEATURE is present, include dependency-def and
2a. If the FEATURE is absent FAIL or
2b. If the FEATURE is absent, quietly succeed.
If the semantics is intended to be the latter -- and that's how I read
the relevant code in find-component.lisp -- how does a programmer say
"if this feature is not present, my system should not compile"?
I stubbed my toe on this absent-mindedly compiling Didier's decLt system
on Allegro Common Lisp.
That system doesn't, and cannot, function on ACL, but ASDF tells us it
has compiled successfully.
Instead, what seems to happen is that the net.didierverna.declt.core
system depends on (:feature :sbcl :sb-introspect) which simply seems to
fail quietly on ACL, in what looks like the worst possible way: the
attempt to laod net.didierverna.declt returns T, the guts of the system
is not loaded (seems like this feature system somehow keeps core from
continuing to load), and no error message is issued.
Actually, I don't claim to understand why this happens -- it looks to me
like RESOLVE-DEPENDENCY-SPEC should return NIL, and the load should
continue (trying to load the :net.didierverna.declt.core system and
succeeding -- or more likely choking when it hits a reference to
:SB-INTROSPECT). But somehow it's failing to load.
I'll see if I can make a minimal test case and file a bug, but I could
use some guidance about what was intended. If the semantics of :FEATURE
are like those of :IF-FEATURE, as I suspect, it seems like they aren't
working here. And, if that's what's intended, how do we get the "fail
if this feture is absent" behavior that a programmer might like?
thanks,
r
[View Less]
I am inclined to agree with Andreas. I don't see that CLEAN-OP is
impossible for ASDF. I can see that there are some issues that require
thought, and for some systems additional coding by the developer, but I
don't see that as an insuperable barrier. After all, "make clean" is in
some sense impossible (it's generally hand-coded by the programmer), but
we use it every day.
I accept Faré's points about there being challenges to write an ideal
CLEAN-OP. But I don't agree that this means that …
[View More]we can't write a good
enough CLEAN-OP. After all, make manages "make clean." Yes, it requires
some effort from the programmer, but who cares? Is that a reason we
have to throw up our hands and refuse to do anything? Here are some
specific responses to particular issues.
On the other hand, while I don't agree that these make the CLEAN-OP
impossible, I *do* agree that they are difficult issues. So... I'd be
happy to see CLEAN-OP added, and I'd be happy to support this effort,
*BUT* CLEAN-OP patches must be preceded -- by an informal specification
that describes what an implementation should do, covering these cases.
Now that ASDF is on everyone's critical path, we need to think a little
before changing it, and not just bash out a hunk of code.
Specific responses to Faré's issues:
1. clean-op is not defined in general. I believe that this means "do we
clean the system" or "do we clean the operation" [as in arnesi, whose
CLEAN-OP has a FOR-OP]?
This seems similar to the notion that Faré already had, of providing a
BUILD-OP that does "the default build action" for a system (e.g., maybe
it builds the library? Maybe it does LOAD-OP? Maybe it does LOAD-OP and
DOC-OP?).
So one solution would be to have an UNMAKE-OP that does the inverse of
the build-op, and then have a CLEAN-OP that undoes specific operations
(like the arnesi CLEAN-OP). Then the UNMAKE-OP might default to being
the CLEAN-OP for COMPILE-OP, which would handle probably 90% of systems.
On the other hand, I'm pretty unhappy with the notion of the BUILD-OP,
because it requires retraining every single user of ASDF to use BUILD-OP
instead of LOAD-OP. That would be an enormous user interface fail. So
this is not a step to be taken lightly.
2. I think we can simply make clean-op clean for the current implementation.
3. I believe we should mirror the semantics of :FORCE T and :FORCE ALL
when we unmake. I.e., unbuild the dependencies only with :FORCE :ALL.
:FORCE T would actually be a no-op.
4. "How do you deal with
defsystem-depends-on and other dependencies not explicitly
included in the plan?" DEFSYSTEM-DEPENDS-ON is already broken, and will
be deprecated, except as a checkable declaration (see earlier postings
on this list for a description of the issues). For the rest, I'd say
same as above -- if there's something that won't appear in the build
plan that one needs to clean, then the programmer must write an
:IN-ORDER-TO for the CLEAN-OP so that ASDF can know what it needs to do.
5. "Are you sure there aren't bugs and
omissions in asdf or any extension whereby some side output file
is omitted from the list?"
ow does make deal with a file that isn't listed in the rule for "make
clean"? You miss it. Very sorry. Fix your system definition. Use
(:in-order-to (clean-op ....))
6. "What about randomly-named temporary
files created during an operation that has been interrupted?" Maybe we
are doing the Wrong Thing with these. If they are temporary files,
maybe it's the wrong thing to put them in the cache and rename them?
Maybe they should live in /tmp (or equivalent) and be moved from there?
Then it's not our problem to fix anymore -- that's for tmpwatch.
If you add your own rules that make temporary files, you have to add
your own rules that remove them.
7. "What if load-op is not the only operation that matters, but
e.g. doc-op generates LaTeX and PDF outputs but fails to be
tracked by clean-op? Are you going to use the CLOS MOP to
generate a list of all possible operations? What if that other
operation isn't loaded in the current image? What if operation
options cause different files to be generated? Or features? What
about all secondary systems? Are you going to generate a plan
for them, too?"
See the answer to #1: ASDF is not going to solve this problem. Either
the programmer solves it using definitions of PERFORM and IN-ORDER-TO,
or it's not solved. So sad. But I don't see any reason to avoid the 90%
solution because there isn't a 100% solution.
Best,
r
[View Less]
I think SBCL commit 25c1769e30ff7404b52a9be663626d87f8ff75bc broke the
use of deferred warnings. If I compile SBCL and exec ./run-sbcl.sh, I
get this error during Quicklisp initialization:
; file: /home/hechee/lisp/quicklisp/quicklisp/impl.lisp
; in: DEFINE-IMPLEMENTATION-PACKAGE :SBCL
; (REQUIRE 'QL-IMPL::SB-POSIX)
;
; caught WARNING:
; completing compilation for #<REQUIRE-SYSTEM "sb-posix"> completed without its output file #P"/home/hechee/work/src/sbcl/obj/sbcl-home/contrib/sb-…
[View More]posix.build-report"
;
; caught WARNING:
; completing load for #<REQUIRE-SYSTEM "sb-posix"> completed without its input file #P"/home/hechee/work/src/sbcl/obj/sbcl-home/contrib/sb-posix.build-report"
; (REQUIRE 'QL-IMPL::SB-BSD-SOCKETS)
;
; caught WARNING:
; completing compilation for #<REQUIRE-SYSTEM "sb-bsd-sockets"> completed without its output file #P"/home/hechee/work/src/sbcl/obj/sbcl-home/contrib/sb-bsd-sockets.build-report"
;
; caught WARNING:
; completing load for #<REQUIRE-SYSTEM "sb-bsd-sockets"> completed without its input file #P"/home/hechee/work/src/sbcl/obj/sbcl-home/contrib/sb-bsd-sockets.build-report"
While evaluating the form starting at line 129, column 0
of #P"/home/hechee/lisp/quicklisp/setup.lisp":
While evaluating the form starting at line 57, column 0
of #P"/home/hechee/.cl-init/asdf-init.lisp":
debugger invoked on a UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread
#<THREAD "main thread" RUNNING {1002FC6A13}>:
COMPILE-FILE-ERROR while compiling #<CL-SOURCE-FILE "quicklisp" "impl">
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry
compiling #<CL-SOURCE-FILE "quicklisp" "impl">.
1: [ACCEPT ] Continue, treating
compiling #<CL-SOURCE-FILE "quicklisp" "impl">
as having been successful.
2: Retry ASDF operation.
3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
configuration.
4: [RETRY ] Retry EVAL of current toplevel form.
5: [CONTINUE ] Ignore error and continue loading file "/home/hechee/lisp/quicklisp/setup.lisp".
6: [ABORT ] Abort loading file "/home/hechee/lisp/quicklisp/setup.lisp".
7: Retry EVAL of current toplevel form.
8: Ignore error and continue loading file "/home/hechee/.cl-init/asdf-init.lisp".
9: Abort loading file "/home/hechee/.cl-init/asdf-init.lisp".
10: Retry EVAL of current toplevel form.
11: Ignore error and continue userinit file "/home/hechee/.sbclrc".
12: Abort userinit file "/home/hechee/.sbclrc".
13: Skip to toplevel READ/EVAL/PRINT loop.
14: [EXIT ] Exit SBCL (calling #'EXIT, killing the process).
(UIOP/LISP-BUILD:CHECK-LISP-COMPILE-RESULTS NIL T T "~/asdf-action::format-action/" ((#<ASDF/LISP-ACTION:COMPILE-OP > . #<ASDF/LISP-ACTION:CL-SOURCE-FILE "quicklisp" "impl">)))
source: (ERROR 'COMPILE-FILE-ERROR :CONTEXT-FORMAT CONTEXT-FORMAT
:CONTEXT-ARGUMENTS CONTEXT-ARGUMENTS)
There's no obj/sbcl-home/contrib/sb-posix.build-report, or any build
-report file, just several test-passed.test-report under obj/asdf
-cache/
Funny though that I don't get this error if I exec sbcl through an
absolute path, e.g. ~/work/src/sbcl/run-sbcl.sh, it's only when I call
it from the source directory as ./run-sbcl.sh
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
[View Less]
I want to do "make clean" on ASDF.
I tried to use clean-op of ARNESI.
I got a following message,
WARNING:
No dependency propagating scheme specified for operation class
IT.BESE.ARNESI:CLEAN-OP.
The class needs to be updated for ASDF 3.1 and specify appropriate
propagation mixins.
#<IT.BESE.ARNESI:CLEAN-OP >
#<ASDF/PLAN:SEQUENTIAL-PLAN {1003A65533}>
Definition of arnesi:clean-op is
(defclass clean-op (asdf:operation)
((for-op :accessor for-op :initarg :for-op :initform …
[View More]'asdf:compile-op))
(:documentation "Removes any files generated by an asdf component."))
(defmethod asdf:perform ((op clean-op) (c asdf:component))
"Delete all the output files generated by the component C."
(dolist (f (asdf:output-files (make-instance (for-op op)) c))
(when (probe-file f)
(delete-file f))))
(defmethod asdf:operation-done-p ((op clean-op) (c asdf:component))
"Returns T when the output-files of (for-op OP) C don't exist."
(dolist (f (asdf:output-files (make-instance (for-op op)) c))
(when (probe-file f) (return-from asdf:operation-done-p nil)))
t)
How to fix it?
Thanks.
ta2gch
[View Less]