Re: Tidy and fix clean and distclean rules for old testsuite.
Hi Gary, * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 06:46:55AM CEST: On 22 Aug 2010, at 11:23, Ralf Wildenhues wrote: OK to apply? Well, it is an improvement over what we have, so... sure, go ahead. Thanks for the quick review! However, I continue to strongly dislike the old testsuite, and would much prefer to migrate it's tests into Autotest. Oh. I was going to propose a patch series to convert the old testsuite to use the parallel-tests driver. Despite the new one having grown nicely, there are still several issues only found with the old one (and some tests in the new one that probably need more work). Oh well. I think I'll still propose the patch series, since it shouldn't make a future migration any worse. I don't intend to work on the migration myself; I prefer spending my time on other things. I understand the argument that our kludgy old tests are good for coverage of libtool with the bootstrapped autotools... but, honestly, I'd rather find out that the libtool I'm planning to install is going to fail with *my* autotools, than I would be told that the old testsuite still passes with whatever versions it happened to be bootstrapped with! Sure. Getting rid of the old testsuite was actually my motivation for starting an Autotest based testsuite in the first place; and because bootstrap and reconf issues with the old testsuite have always been (and continue to be) a real pain. And look what the new testsuite gained us: much better test coverage! In that way I think it's a huge success even if it hasn't (yet) achieved the goal you intended it for. :-) Cheers, Ralf
Re: Tidy and fix clean and distclean rules for old testsuite.
Hallo Ralf, On 22 Aug 2010, at 17:29, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 06:46:55AM CEST: On 22 Aug 2010, at 11:23, Ralf Wildenhues wrote: However, I continue to strongly dislike the old testsuite, and would much prefer to migrate it's tests into Autotest. Oh. I was going to propose a patch series to convert the old testsuite to use the parallel-tests driver. Despite the new one having grown nicely, there are still several issues only found with the old one (and some tests in the new one that probably need more work). Oh well. I think I'll still propose the patch series, since it shouldn't make a future migration any worse. I don't intend to work on the migration myself; I prefer spending my time on other things. Sure, a step forward is a step forward. And besides I might not find the time to work on migrating the old tests for a long while, and have a less annoying old testsuite is definitely a good thing in my book :) I understand the argument that our kludgy old tests are good for coverage of libtool with the bootstrapped autotools... but, honestly, I'd rather find out that the libtool I'm planning to install is going to fail with *my* autotools, than I would be told that the old testsuite still passes with whatever versions it happened to be bootstrapped with! Sure. Getting rid of the old testsuite was actually my motivation for starting an Autotest based testsuite in the first place; and because bootstrap and reconf issues with the old testsuite have always been (and continue to be) a real pain. And look what the new testsuite gained us: much better test coverage! Yes indeed! In that way I think it's a huge success even if it hasn't (yet) achieved the goal you intended it for. :-) That's great. I could have sworn that we discussed this and reached a consensus that the old tests should stay... but a quick search through the archives didn't turn up the conversation I thought I'd remembered. I would have done the work to migrate long ago if my memory hadn't been implanted by aliens (8 I've added it to my TODO, so it should arrive here at some point in the not too distant future. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Tidy and fix clean and distclean rules for old testsuite.
In the Libtool tree, invoking 'make distclean' after 'make clean' or before 'make check' has ever run, fails because there are no Makefiles in the old test subdirectories (and automake's distclean rule looks at DIST_SUBDIRS not SUBDIRS). This patch fixes this long-standing error by creating stub Makefiles, and IMHO using minimal insider information about Automake-generated rules: basically only the name of the 'distclean-recursive' rule, to which we must add a prerequisite. Just adding to distclean-local doesn't work, that gets invoked too late. OK to apply? Even with this patch, 'make clean' may be very slow in the case where the test subdirectories need reconfiguring. That is an orthogonal and IMVHO minor issue, which I don't know how fix easily though. Thanks, Ralf Tidy and fix clean and distclean rules for old testsuite. * Makefile.am (clean-local-legacy): Use $(CONF_SUBDIRS) instead of hard-coding the list of test directories. Use $(AM_MAKEFLAGS). (fake-distclean-legacy): New phony rule, to create fake Makefile files if needed so that the automake-generated distclean-recursive rule can work properly. (distclean_recursive): New helper variable. (distclean-recursive): Depend on fake-distclean-legacy. diff --git a/Makefile.am b/Makefile.am index d689e09..2c4a3db 100644 --- a/Makefile.am +++ b/Makefile.am @@ -712,12 +712,26 @@ $(srcdir)/tests/defs.in: $(auxdir)/general.m4sh tests/defs.m4sh Makefile.am # We need to remove any files that the above tests created. clean-local-legacy: - -cd tests; \ - for dir in cdemo demo depdemo f77demo fcdemo mdemo mdemo2 pdemo tagdemo; \ - do \ - test -f $$dir/Makefile ( cd $$dir $(MAKE) distclean; ); \ + -for dir in $(CONF_SUBDIRS); do \ + if test -f $$dir/Makefile; then \ + (cd $$dir $(MAKE) $(AM_MAKEFLAGS) distclean); \ + else :; fi; \ done rm -rf _inst +# For distclean, we may have to fake Makefiles in the test directories +# so that descending in DIST_SUBDIRS works. +# Hide the additional dependency from automake so it still outputs the rule. +distclean_recursive = distclean-recursive +$(distclean_recursive): fake-distclean-legacy +.PHONY: fake-distclean-legacy +fake-distclean-legacy: + -for dir in $(CONF_SUBDIRS); do \ + if test ! -f $$dir/Makefile; then \ + $(mkinstalldirs) $$dir; \ + echo 'distclean: ; rm -f Makefile' $$dir/Makefile; \ + else :; fi; \ + done + $(TESTS): tests/defs DISTCLEANFILES += tests/defs
Re: Tidy and fix clean and distclean rules for old testsuite.
Hallo Ralf, On 22 Aug 2010, at 11:23, Ralf Wildenhues wrote: In the Libtool tree, invoking 'make distclean' after 'make clean' or before 'make check' has ever run, fails because there are no Makefiles in the old test subdirectories (and automake's distclean rule looks at DIST_SUBDIRS not SUBDIRS). This patch fixes this long-standing error by creating stub Makefiles, and IMHO using minimal insider information about Automake-generated rules: basically only the name of the 'distclean-recursive' rule, to which we must add a prerequisite. Just adding to distclean-local doesn't work, that gets invoked too late. OK to apply? Well, it is an improvement over what we have, so... sure, go ahead. However, I continue to strongly dislike the old testsuite, and would much prefer to migrate it's tests into Autotest. I understand the argument that our kludgy old tests are good for coverage of libtool with the bootstrapped autotools... but, honestly, I'd rather find out that the libtool I'm planning to install is going to fail with *my* autotools, than I would be told that the old testsuite still passes with whatever versions it happened to be bootstrapped with! Getting rid of the old testsuite was actually my motivation for starting an Autotest based testsuite in the first place; and because bootstrap and reconf issues with the old testsuite have always been (and continue to be) a real pain. Even with this patch, 'make clean' may be very slow in the case where the test subdirectories need reconfiguring. That is an orthogonal and IMVHO minor issue, which I don't know how fix easily though. I do: see the first six words of my last para ;) Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
