diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/automake.texi | 28 |
1 files changed, 3 insertions, 25 deletions
diff --git a/doc/automake.texi b/doc/automake.texi index 74a410177..91b4a0a7d 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -1900,9 +1900,6 @@ It is customary to make the first line of @file{Makefile.am} read: ## Process this file with automake to produce Makefile.in @end example -@c FIXME discuss putting a copyright into Makefile.am here? I would but -@c I don't know quite what to say. - @c FIXME document customary ordering of Makefile.am here! @@ -8821,9 +8818,6 @@ error} happens when e.g., the set-up of a test case scenario fails, or when some other unexpected or highly undesirable condition is encountered (for example, the program under test experiences a segmentation fault). -@emph{TODO}: Links to other test harnesses (esp. those sharing our -terminology)? - @node Simple Tests @section Simple Tests @@ -8956,8 +8950,6 @@ flag on file descriptors opened with the @command{exec} builtin, thus rendering an idiom like @code{AM_TESTS_ENVIRONMENT = exec 9>&2;} ineffectual. This issue also affects some Bourne shells, such as the HP-UX's @command{/bin/sh}, -@c FIXME: should we offer a link to the relevant discussions on the -@c bug-autoconf list? @c Keep in sync with tests-environment-backcompat.sh @example @@ -9017,7 +9009,6 @@ The serial test harness is enabled by the Automake option @option{serial-tests}. It operates by simply running the tests serially, one at the time, without any I/O redirection. It's up to the user to implement logging of tests' output, if that's requited or desired. -@c TODO: give an example of how this can be done. For historical and implementation reasons, the @code{AM_TESTS_ENVIRONMENT} variable is @emph{not} supported by this harness (it will be silently @@ -9086,8 +9077,6 @@ to a per-test log file, so that parallel execution does not produce intermingled output. The output from failed tests is collected in the @file{test-suite.log} file. If the variable @samp{VERBOSE} is set, this file is output after the summary. -@c FIXME: we should be clearer about what we mean exactly here ... -For best results, the tests should be verbose by default now. @vindex TEST_EXTENSIONS @vindex TEST_LOGS @@ -9596,12 +9585,6 @@ other end, if you are using a known and widespread test protocol with well-established implementations, being consistent with those implementations' output might be a good idea too. -@c TODO: Give an example, maybe inspired to py.test-style output. -@c TODO: That is a good idea because it shows a test driver that allows -@c TODO: for different levels of verbosity in the progress output (could -@c TODO: be implemented either using a driver cmdline flag, or an -@c TODO: environment variable, or both). - @node Using the TAP test protocol @section Using the TAP test protocol @@ -9650,10 +9633,9 @@ Currently, the TAP driver that comes with Automake requires some by-hand steps on the developer's part (this situation should hopefully be improved in future Automake versions). You'll have to grab the @file{tap-driver.sh} script from the Automake distribution by hand, copy it in your source tree, -add a call to @code{AC_PROG_AWK} in @file{configure.ac} to search for a -proper awk program, and use the Automake support for third-party test -drivers to instruct the harness to use the @file{tap-driver.sh} script -and that awk program to run your TAP-producing tests. See the example +and use the Automake support for third-party test drivers to instruct the +harness to use the @file{tap-driver.sh} script and the awk program found +by @code{AM_INIT_AUTOMAKE} to run your TAP-producing tests. See the example below for clarification. Apart from the options common to all the Automake test drivers @@ -9709,7 +9691,6 @@ AC_CONFIG_AUX_DIR([build-aux]) AM_INIT_AUTOMAKE([foreign -Wall -Werror]) AC_CONFIG_FILES([Makefile]) AC_REQUIRE_AUX_FILE([tap-driver.sh]) -AC_PROG_AWK AC_OUTPUT % @kbd{cat Makefile.am} @@ -10838,9 +10819,6 @@ they all have their serious drawbacks and limitations. That's why automake provides support for a more advanced and flexible way of obtaining quieter output from @command{make} (for most rules at least). -@c TODO: Maybe describe in brief the precedent set by the build system -@c of the Linux Kernel, from which Automake took inspiration ... Links? - To give the gist of what Automake can do in this respect, here is a simple comparison between a typical @command{make} output (where silent rules are disabled) and one with silent rules enabled: |