On Friday 25 November 2011, Gary V wrote: > On 25 Nov 2011, at 18:59, Stefano Lattarini wrote: > > On Friday 25 November 2011, Gary V wrote: > >> > >> The best reason I can find for keeping the various demo directories > >> around (despite the fact we already make use of the much better test > >> harness of Autotest for all our new test cases) from the last time > >> I wanted to migrate everything out of the legacy testsuite, was that > >> it exercises the distribution manager's autotools combination on the > >> testers machine, where the Autotests always use the users autotools. > >> That's no argument as far as I can see: we want tests to fail as > >> early as possible on a users machine to help him know things are not > >> going to work properly if he keeps going - and having the legacy > >> suite pass is only encouraging users to fight with broken installs. > >> > >> This series of patches migrates all 9 of the demo directory test > >> groups into Autotest, and allows us to remove most of the legacy > >> testsuite cruft at the end. > >> > > Just my 2 cents: I'd like to see the test scripts converted one at > > the time, rather than one group at the time (and assuming that this > > is feasible), as I found your huge patches basically un-reviewable > > in their present state. > > The legacy tests are in sets that can't be broken apart without leaving > the tree in an inconsistent state part way through that set. > Oh. I thought you could convert them one at the time instead, but they are inter-dependent, this could become more cumbersome, if not almost impossible. > I could break them up a little more tho', if you think that would help, > so instead of converting one demo directory all at once, then a final > patch to clean out the configury cruft... there'd be 9 sets of patches > each containing almost everything in the current patch, except the > deletion of the the files in the given test/demo directory, followed by > a series of tiny patches each adding a dozen lines like this: > > +## ----------- ## > +## Mdemo conf. ## > +## ----------- ## > + > +AT_SETUP([ltdl load shared and static modules]) > + > +_LT_SETUP > + > +_LT_CHECK_CONFIG([], [^build_old_libs=yes], [^build_libtool_libs=yes]) > +_LT_CHECK_EXECUTE > +_LT_CHECK_INSTALL > +_LT_CHECK_UNINSTALL > + > +AT_CLEANUP > > plus removing the equivalent legacy set of 3 *.test files, and then a > final patch to delete the given test/demo tree, and relevant lines from > Makefile.am. > > It'll take me a while to go through and do that, and we'll end up with > 10 large patches each setting up a new tests/demo.at file, about 25 > tiny patches per the above, then 10 small patches each removing one of > the tests/demo trees, and then the final cruft cleanout patch unchanged. > > If that will make a big difference, let me know and I'll retract these > patches and post 50 or so to replace them in a week or two when I've > gone through and broken out the tiny per-test-group sets per the above. > Nah, let's forget about this. I thought that breaking up your patches further could be done easily and naturally, but if it is not the case, I see no real gain in the extra churn.
> >> There's still a few legacy tests > >> left at the end, which I'll tackle later, but at least maintenance > >> is a whole lot easier now that we don't need to wait for 9 additional > >> directories to autoreconf every time we run bootstrap, or distcheck, > >> or roll up a distribution tarball to test on the local network. > >> > >> This is all in keeping with the theme of most of the patches I've > >> posted this year, to make libtool easier and more fun to maintain > >> and contribute to, in the hope of getting more people involved. > >> > >> As usual, subject to feedback, I'll push this whole series in > >> 72 hours or so. Make distcheck passes for me on my Mac 10.7 and > >> my Arch Linux x86_64 machines, but it would be great if folks with > >> access to other machines could give it a spin to see whether I > >> broke any of the tests during migration... if you'd like a pre- > >> rolled distro with my pending patches applied to do that, then > >> please do ask. > >> > > If you want to send me such a tarball, I might run the testsuite on > > Solaris 10, Cygwin 1.5.25, NetBSD 5.1 and OpenBSD 4.6 at least. > > Much appreciated. Tarballs here: > > http://vaughan.pe/libtool/libtool-2.4.2.135-aa59c.tar.gz > http://vaughan.pe/libtool/libtool-2.4.2.135-aa59c.tar.xz > > > But > > then you should allow for more than three days for sending feedback > > -- at least a week. > > That's fine, and running on those arches would be a great help in > giving me confidence the migration didn't break anything. > > It'll take me at least a week to redo everything into smaller pieces > anyway... (unless you think the time spent here will not make much > difference to your review). But do let me know either way :) > Done above :-) Don't bother in breaking up the series. > And thanks also for offering to make the time to look them over. > If you meant testing them, that won't require much time from me -- the machines will do basically all the work ;-) Regards, Stefano
