GNU bug report logs -
#11287
Various issues with the test suite framework
Previous Next
Reported by: Akim Demaille <akim <at> lrde.epita.fr>
Date: Fri, 20 Apr 2012 11:26:01 UTC
Severity: normal
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#11287: Various issues with the test suite framework
which was filed against the automake package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 11287 <at> debbugs.gnu.org.
--
11287: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11287
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Reference: <http://debbugs.gnu.org/11287>
To sum up the actions related to this bug report:
On 04/20/2012 01:13 PM, Akim Demaille wrote:
> Hi!
>
> I have seen that check-html will be removed, or rather moved
> into the contrib part, but there are a few issues:
>
> - the target is not declared recursive, so one has to write
> the bouncing target herself.
>
This isn't a big deal anymore, now that the user can define extra
recursive targets through the macro AM_EXTRA_RECURSIVE_TARGETS
(features introduced in commit v1.12.1-163-g3da1457); the test
'contrib/t/parallel-tests-html-recursive.sh' (introduced by commit
v1.12.1-191-g53d4984) should prove this assertion.
> - because of that, the "naive" implementation of check-html
> that just bounces the right directories will miss the
> dependencies that check features (in other words, make
> check properly recursively builds before, while check-html
> would just go into the typical tests/ directory, and then
> bounce to "check", so it completely missed the recursion
> in the other directories and their dependencies).
>
Adding 'check-html' to AM_EXTRA_RECURSIVE_TARGETS should take
care of this issue as well.
> - RECURSIVE_TARGETS cannot be highjacked by the users, that's
> sad. Could a $(USER_RECURSIVE_TARGETS) be added to
> RECURSIVE_TARGETS so that we can add our own targets that
> traverse the whole package? Actually maybe this should
> be an Automake option to add recursive targets, and
> then TARGET-am and TARGET-recursive would be generated and
> bound to the proper TARGET.
>
Addressed by commit v1.12.1-163-g3da1457 (with a different design
but comparable functionalities); see this thread for more info:
<http://lists.gnu.org/archive/html/automake-patches/2012-06/msg00195.html>
> - the .log.html recipe features $$RST2HTML, but in '', so it is
> useless. And anyway $(RST2HTML) already does the job.
>
Agreed. Fixed by commit v1.12.1-192-g18dac90.
> - "$(AM_RST2HTMLFLAGS) $(RST2HTMLFLAGS)" is missing.
>
Fixed by commit v1.12.1-193-g67abae4.
> - the test compiler does not appear as a dependency for
> the test logs that use it.
>
Reporting what I've stated in an earlier reply:
This makes sense, since the test compiler is not required to be
an in-project script, and not even to be specified as an absolute
path -- it can be a command like "sh" or "/usr/bin/env perl".
> (This is most useful when RECHECK_LOG =.)
> - it would be equally useful to be able to add dependencies
> to a category of test drivers. Say, with the documented
> example:
>
> TESTS = foo.pl bar.py baz
> TEST_EXTENSIONS = .pl .py
> PL_LOG_COMPILER = $(PERL)
> AM_PL_LOG_FLAGS = -w
> PY_LOG_COMPILER = $(PYTHON)
> AM_PY_LOG_FLAGS = -v
> LOG_COMPILER = ./wrapper-script
> AM_LOG_FLAGS = -d
>
> be able to add PL_LOG_DEPENDENCIES, PY_LOG_DEPENDENCIESS and
> LOG_DEPENDENCIES. I don't think EXTRA dependencies would
> be useful.
>
This would be tricky to implement in the current Automake code base, and
IMHO for a too little benefit; so I'm going to label this part of the
report as a "wontfix". However, it was easy to implement in Automake-NG:
<http://lists.gnu.org/archive/html/automake-ng/2012-05/msg00022.html>
-*-*-*-
All that considered, I'm closing this bug report now.
Regards,
Stefano
[Message part 3 (message/rfc822, inline)]
Hi!
I have seen that check-html will be removed, or rather moved
into the contrib part, but there are a few issues:
- the target is not declared recursive, so one has to write
the bouncing target herself.
- because of that, the "naive" implementation of check-html
that just bounces the right directories will miss the
dependencies that check features (in other words, make
check properly recursively builds before, while check-html
would just go into the typical tests/ directory, and then
bounce to "check", so it completely missed the recursion
in the other directories and their dependencies).
- RECURSIVE_TARGETS cannot be highjacked by the users, that's
sad. Could a $(USER_RECURSIVE_TARGETS) be added to
RECURSIVE_TARGETS so that we can add our own targets that
traverse the whole package? Actually maybe this should
be an Automake option to add recursive targets, and
then TARGET-am and TARGET-recursive would be generated and
bound to the proper TARGET.
- the .log.html recipe features $$RST2HTML, but in '', so it is
useless. And anyway $(RST2HTML) already does the job.
- "$(AM_RST2HTMLFLAGS) $(RST2HTMLFLAGS)" is missing.
- the test compiler does not appear as a dependency for
the test logs that use it. This is most useful when
RECHECK_LOG =.
- it would be equally useful to be able to add dependencies
to a category of test drivers. Say, with the documented
example:
TESTS = foo.pl bar.py baz
TEST_EXTENSIONS = .pl .py
PL_LOG_COMPILER = $(PERL)
AM_PL_LOG_FLAGS = -w
PY_LOG_COMPILER = $(PYTHON)
AM_PY_LOG_FLAGS = -v
LOG_COMPILER = ./wrapper-script
AM_LOG_FLAGS = -d
be able to add PL_LOG_DEPENDENCIES, PY_LOG_DEPENDENCIESS and
LOG_DEPENDENCIES. I don't think EXTRA dependencies would
be useful.
Cheers!
This bug report was last modified 13 years and 38 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.