Skip to content
GitLab
Projects
Groups
Snippets
Help
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
A
asdf
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
15
Issues
15
List
Boards
Labels
Service Desk
Milestones
Merge Requests
9
Merge Requests
9
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Incidents
Environments
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
asdf
asdf
Commits
b1b2f78a
Commit
b1b2f78a
authored
Apr 06, 2014
by
Robert P. Goldman
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Rewrite description of TEST-OP.
parent
d19a46a9
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
29 additions
and
21 deletions
+29
-21
doc/asdf.texinfo
doc/asdf.texinfo
+29
-21
No files found.
doc/asdf.texinfo
View file @
b1b2f78a
...
@@ -1863,6 +1863,8 @@ To see what @code{operate} would do, you can use:
...
@@ -1863,6 +1863,8 @@ To see what @code{operate} would do, you can use:
@node Predefined operations of ASDF, Creating new operations, Operations, Operations
@node Predefined operations of ASDF, Creating new operations, Operations, Operations
@comment node-name, next, previous, up
@comment node-name, next, previous, up
@subsection Predefined operations of ASDF
@subsection Predefined operations of ASDF
@c FIXME: All these deffn's should be replaced with deftyp. Also, we
@c should set up an appropriate index.
All the operations described in this section are in the @code
{
asdf
}
package.
All the operations described in this section are in the @code
{
asdf
}
package.
They are invoked via the @code
{
operate
}
generic function.
They are invoked via the @code
{
operate
}
generic function.
...
@@ -1912,7 +1914,7 @@ may be performed on a given component.
...
@@ -1912,7 +1914,7 @@ may be performed on a given component.
@deffn Operation @code
{
load-source-op
}
, @code
{
prepare-source-op
}
@deffn Operation @code
{
load-source-op
}
, @code
{
prepare-source-op
}
@code
{
load-source-op
}
will load the source for the files in a module
@code
{
load-source-op
}
will load the source for the files in a module
rather than the
y
compiled fasl output.
rather than the compiled fasl output.
It has a @code
{
prepare-source-op
}
analog to @code
{
prepare-op
}
,
It has a @code
{
prepare-source-op
}
analog to @code
{
prepare-op
}
,
that ensures the dependencies are themselves loaded via @code
{
load-source-op
}
.
that ensures the dependencies are themselves loaded via @code
{
load-source-op
}
.
...
@@ -1945,28 +1947,34 @@ The results of this operation are not defined by ASDF.
...
@@ -1945,28 +1947,34 @@ The results of this operation are not defined by ASDF.
It has proven difficult to define how the test operation
It has proven difficult to define how the test operation
should signal its results to the user
should signal its results to the user
in a way that is compatible with all of the various test libraries
in a way that is compatible with all of the various test libraries
and test techniques in use in the community.
and test techniques in use in the community, and
given the fact that ASDF operations do not return a value indicating
success or failure.
For those willing to go to the effort, we suggest defining conditions to
signal when a @code
{
test-op
}
fails, and storing in those conditions
information that describes which tests fail.
People typically define a separate test @emph
{
system
}
to hold the tests.
Doing this avoids unnecessarily adding a test framework as a dependency
on a library. For example, one might have
@lisp
(defsystem foo
:in-order-to ((test-op (test-op "foo/test")))
...)
(defsystem foo/test
:depends-on (foo fiveam) ; fiveam is a test framework library
...)
@end lisp
People typically define @code
{
test-op
}
methods like thus:
Then one defines @code
{
perform
}
methods on
@example
@code
{
test-op
}
such as the following:
@lisp
(defmethod perform ((o asdf:test-op)
(defmethod perform ((o asdf:test-op)
(s (eql (asdf:find-system @var
{
:my-system
}
))))
(s (eql (asdf:find-system @var
{
:foo/test
}
))))
(asdf:load-system @var
{
:my-system-test
}
)
(funcall (intern (symbol-name '#:run!) :fiveam)
(funcall (read-from-string "my-system-test:test-suite")))
(intern (symbol-name '#:foo-test-suite) :foo-tests)))
@end example
@end lisp
Using @code
{
load-system
}
in the perform method
rather than an @code
{
:in-order-to
}
dependency,
is sometimes necessary for backward compatibility with ASDF 2 and older,
to avoid circular dependencies that could arise
because of the way these old versions propagate dependencies.
If you don't care for compatibility with ASDF 2,
you could use the following options in your @code
{
defsystem
}
form:
@example
:in-order-to ((test-op (load-op :my-system-test)))
:perform (test-op (o c) (symbol-call :my-system-test :test-suite))
@end example
@end deffn
@end deffn
@deffn Operation @code
{
fasl-op
}
, @code
{
monolithic-fasl-op
}
, @code
{
load-fasl-op
}
, @code
{
binary-op
}
, @code
{
monolithic-binary-op
}
, @code
{
lib-op
}
, @code
{
monolithic-lib-op
}
, @code
{
dll-op
}
, @code
{
monolithic-dll-op
}
, @code
{
program-op
}
@deffn Operation @code
{
fasl-op
}
, @code
{
monolithic-fasl-op
}
, @code
{
load-fasl-op
}
, @code
{
binary-op
}
, @code
{
monolithic-binary-op
}
, @code
{
lib-op
}
, @code
{
monolithic-lib-op
}
, @code
{
dll-op
}
, @code
{
monolithic-dll-op
}
, @code
{
program-op
}
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment