From 0c319e63eb4054268604048d0b07c81b97a1b5ee Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman" <rpgoldman@gmail.com>
Date: Sun, 6 Apr 2014 12:07:24 -0500
Subject: [PATCH] Cut down the TEST-OP discussion in FAQ.

It's now redundant with the definition of the TEST-OP built-in operation
class.  I don't want to have to maintain two separate discussions of the
same material.
---
 doc/asdf.texinfo | 75 ++++++++++++++++++++++++------------------------
 1 file changed, 38 insertions(+), 37 deletions(-)

diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo
index d0174ac1..7faad5a0 100644
--- a/doc/asdf.texinfo
+++ b/doc/asdf.texinfo
@@ -5017,7 +5017,6 @@ use (after loading ASDF but before using it):
 
 @node How can I cater for unit-testing in my system?, How can I cater for documentation generation in my system?, Issues with using and extending ASDF to define systems, Issues with using and extending ASDF to define systems
 @subsection ``How can I cater for unit-testing in my system?''
-@c FIXME: cross-reference the TEST-OP section.
 
 ASDF provides a predefined test operation, @code{test-op}.
 @xref{Predefined operations of ASDF, test-op}.
@@ -5027,48 +5026,50 @@ a topic of considerable discussion on the
 @url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list},
 and on the
 @url{https://launchpad.net/asdf,launchpad bug-tracker}.
+We provide some guidelines in the discussion of @code{test-op}.
 
-Here are some guidelines:
+@c cut the following because it's discussed in the discussion of test-op.
+@c Here are some guidelines:
 
-@itemize
-@item
-For a given system, @var{foo}, you will want to define a corresponding
-test system, such as @var{foo-test}.  The reason that you will want this
-separate system is that ASDF does not out of the box supply components
-that are conditionally loaded.  So if you want to have source files
-(with the test definitions) that will not be loaded except when testing,
-they should be put elsewhere.
-
-@item
-The @var{foo-test} system can be defined in an asd file of its own or
-together with @var{foo}.  An aesthetic preference against cluttering up
-the filesystem with extra asd files should be balanced against the
-question of whether one might want to directly load @var{foo-test}.
-Typically one would not want to do this except in early stages of
-debugging.
+@c @itemize
+@c @item
+@c For a given system, @var{foo}, you will want to define a corresponding
+@c test system, such as @var{foo-test}.  The reason that you will want this
+@c separate system is that ASDF does not out of the box supply components
+@c that are conditionally loaded.  So if you want to have source files
+@c (with the test definitions) that will not be loaded except when testing,
+@c they should be put elsewhere.
 
-@item
-Record that testing is implemented by @var{foo-test}.  For example:
-@example
-(defsystem @var{foo}
-   :in-order-to ((test-op (test-op @var{foo-test})))
-   ....)
+@c @item
+@c The @var{foo-test} system can be defined in an asd file of its own or
+@c together with @var{foo}.  An aesthetic preference against cluttering up
+@c the filesystem with extra asd files should be balanced against the
+@c question of whether one might want to directly load @var{foo-test}.
+@c Typically one would not want to do this except in early stages of
+@c debugging.
 
-(defsystem @var{foo-test}
-   :depends-on (@var{foo} @var{my-test-library} ...)
-   ....)
-@end example
-@end itemize
+@c @item
+@c Record that testing is implemented by @var{foo-test}.  For example:
+@c @example
+@c (defsystem @var{foo}
+@c    :in-order-to ((test-op (test-op @var{foo-test})))
+@c    ....)
+
+@c (defsystem @var{foo-test}
+@c    :depends-on (@var{foo} @var{my-test-library} ...)
+@c    ....)
+@c @end example
+@c @end itemize
 
-This procedure will allow you to support users who do not wish to
-install your test framework.
+@c This procedure will allow you to support users who do not wish to
+@c install your test framework.
 
-One oddity of ASDF is that @code{operate} (@pxref{Operations,operate})
-does not return a value.  So in current versions of ASDF there is no
-reliable programmatic means of determining whether or not a set of tests
-has passed, or which tests have failed.  The user must simply read the
-console output.  This limitation has been the subject of much
-discussion.
+@c One oddity of ASDF is that @code{operate} (@pxref{Operations,operate})
+@c does not return a value.  So in current versions of ASDF there is no
+@c reliable programmatic means of determining whether or not a set of tests
+@c has passed, or which tests have failed.  The user must simply read the
+@c console output.  This limitation has been the subject of much
+@c discussion.
 
 @node How can I cater for documentation generation in my system?, How can I maintain non-Lisp (e.g. C) source files?, How can I cater for unit-testing in my system?, Issues with using and extending ASDF to define systems
 @subsection ``How can I cater for documentation generation in my system?''
-- 
GitLab