Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
On 11/28/2011 12:12 PM, Charles Wilson wrote:
Attached, see test log for $host=cygwin. I had to use 'make -k check
gl_public_submodule_commit=' -- I'm not sure why, but perhaps your
working tree is using private gnulib mods?
I'll send testsuite.dir privately.
I've attached the test log for $host=mingw32. I'll send /that/
testsuite.dir privately, as well.
--
Chuck
make check-recursive
make[1]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
GENtests/defs
Making check in .
make[2]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd ../libtool && \
rm -rf $backupdir && mkdir $backupdir && \
if (/bin/sh
/c/cygwin-1.7/usr/src/packages/libtool/git/libtool/build-aux/missing --run
makeinfo --version) >/dev/null 2>&1; then \
for f in ../libtool/doc/libtool.info
../libtool/doc/libtool.info-[0-9] ../libtool/doc/libtool.info-[0-9][0-9]
../libtool/doc/libtool.i[0-9] ../libtool/doc/libtool.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
else :; fi && \
cd "$am__cwd"; \
if /bin/sh
/c/cygwin-1.7/usr/src/packages/libtool/git/libtool/build-aux/missing --run
makeinfo -I doc -I ../libtool/doc \
-o ../libtool/doc/libtool.info ../libtool/doc/libtool.texi; \
then \
rc=0; \
CDPATH="${ZSH_VERSION+.}:" && cd ../libtool; \
else \
rc=$?; \
CDPATH="${ZSH_VERSION+.}:" && cd ../libtool && \
$restore $backupdir/* `echo "./../libtool/doc/libtool.info" | sed
's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
make check-TESTS check-local
make[3]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
make[4]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
PASS: tests/link.test
PASS: tests/link-2.test
PASS: tests/nomode.test
PASS: tests/objectlist.test
PASS: tests/quote.test
PASS: tests/suffix.test
PASS: tests/tagtrace.test
==
All 7 tests passed
==
make[4]: Leaving directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
CC libltdl/loaders/libltdl_libltdlc_la-preopen.lo
CC libltdl/libltdl_libltdlc_la-lt__alloc.lo
CC libltdl/libltdl_libltdlc_la-lt_dlloader.lo
CC libltdl/libltdl_libltdlc_la-lt_error.lo
CC libltdl/libltdl_libltdlc_la-ltdl.lo
CC libltdl/libltdl_libltdlc_la-slist.lo
CCLD libltdl/libltdlc.la
## - ##
## GNU Libtool 2.4.2.133-fe91d-dirty test suite. ##
## - ##
Shell option parser generator.
1: short option splitting ok
2: enhanced shell short option splitting ok
3: long option splitting ok
4: XSI long option splitting ok
5: option appendingok
6: enhanced shell option appending ok
Libtoolize operation.
7: libtoolize macro installation ok
8: libtoolize macro directory mismatch error ok
9: libtoolize macro serial update FAILED (libtoolize.at:151)
10: libtoolize config files serial update FAILED (libtoolize.at:228)
11: diagnose missing LT_CONFIG_LTDL_DIR ok
12: copy ltdl.m4 with shared macro directoryok
13: correctly parse LTDL_INIT from configure.ac ok
14: diagnose missing LTDL_INIT invocation ok
15: upgrading verbatim style aclocal.m4 FAILED (libtoolize.at:594)
16: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR FAILED (libtoolize.at:685)
17: nonrecursive ltdl with AC_CONFIG_MACRO_DIR ok
18: subproject ltdl with unconventional layout ok
19: Subproject ltdl without GNU M4 ok
20: LIBTOOLIZE_OPTIONS ok
21: cleanup old installationok
Linking and loading.
22: link against a preloaded static library FAILED (demo.at:398)
23: build and dynamically load a module FAILED (demo.at:415)
24: preload static and dynamic module FAILED (demo.at:432)
25: deplibs_check_methodFAILED (demo.at:478)
26: disable fast installFAILED (demo.at:494)
27: force PIC objects FAILED (demo.at:510)
28: force non-PIC objects FAILED (demo.at:548)
29: hardcoding library path FAILED (demo.at:621)
30: binary relinking at install timeFAILED (demo.at:730)
31: uninstalled libraries have priority FAILED (demo.at:791)
32: linking with long file namesFAI
Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
On 11/25/2011 11:57 PM, Gary V. Vaughan wrote: > On 26 Nov 2011, at 11:39, Charles Wilson wrote: >> a) This is a big holiday weekend in the US, so...a bit more than 72 >> hours is indicated. Most of us will still be catching up on >> post-holiday $realjob stuff by the time 72 hours expires. > > Ah, didn't think of that. Sure, I will be busy myself for a week or > two, so I won't push for at least a week, probably more. Thanks. >> b) cygwin? mingw? msvc? > > I'm afraid I don't have (or want) access to any Windows machines, so > I'm afraid that I am relying on you guys to tell me if I screwed up. > Of course I'm not expecting you to debug or fix my mistakes for me, > and I'm not anticipating any new problems, since everything is merely > migrated from legacy testsuite to Autotest testsuite, with minimal > changes required to keep everything working on my main machines. Hrm, well, not so much. See below. > Although I do normally have access to more machines, the flooding in > Bangkok has made any use of my Internet connection other than email > intolerably slow... hence the recent flurry of work on libtool (which > I can do offline, queueing emails for when my connection is next up) Ah, well, $realjob's loss, our gain. > to fill my time while I wait for things to get back to normal. The > reason I'll be too busy to do much more of that over the next week or > two, is that last night I actually had a full-speed connection to the > US again, so I'm anticipating playing catchup at $realjob myself. > >> Sorry if I seem a bit short, but I'm rather annoyed to see my queue >> get filled with hours upon hours of work in the middle of a >> holiday. > > Please don't feel that it's your responsibility to painstakingly pick > through every patch I post... I'd be more than happy just to get the > test logs from anything I put on alpha.gnu.org for the architectures > I don't use to help me restabilize the code closer to a release. Full test logs for failed cygwin tests sent privately (1MB). > Enjoy the rest of your holiday, and sorry for working so much on > libtool recently: Well, I really wasn't complaining about the *work* per se -- it's great that "somebody" is finally tackling some of those gee-wouldn't-it-be-nice issues, like *FINALLY* switching over to autotest throughout, with all the attendant benefits. It's just I didn't want to have to run the testsuite, on three platforms, over the holidays in order to meet the 72hour deadline. > although my objective with the recent > modernisations has been to try to decruft libtool a little, and to > make the barrier to contribution much lower than it is currently if > at all possible. decrufting is good. > I rarely have the chance to put a lot of time into > libtool, and things will slow down considerably again now if my > Internet connection really is back to (something like) normal again. Yep, when the tool mostly "Just Works" the motivation to allocate scarce resources (like personal free time) to it is somewhat lacking. I think that's true for all of us. > I have another 20 or so patches left incubating in my unpublished > queue, and I will be done for now after those are polished and pushed > over the next month or two. Too bad. If your inet stayed down longer, I was going to suggest implementing the long-desired "if $CC=gcc && $gnuld == yes; then use compiler driver to link rather than ld, for all languages" optimization -- thus getting rid of the predeps/postdeps/prelibs/postlibs kludginess for GNU compilers (incl. cygming). Oh well. :-) Attached, see test log for $host=cygwin. I had to use 'make -k check gl_public_submodule_commit=' -- I'm not sure why, but perhaps your working tree is using private gnulib mods? I'll send testsuite.dir privately. -- Chuck make check-recursive make[1]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master' GEN../libtool/tests/defs.in GENtests/defs Making check in . make[2]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master' make check-TESTS check-local make[3]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master' make[4]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master' PASS: tests/link.test PASS: tests/link-2.test PASS: tests/nomode.test PASS: tests/objectlist.test PASS: tests/quote.test PASS: tests/suffix.test PASS: tests/tagtrace.test == All 7 tests passed == make[4]: Leaving directory `/usr/src/packages/libtool/git/build-libtool-master' GEN../libtool/tests/package.m4 GEN../libtool/tests/testsuite CC libltdl/loaders/libltdl_libltdlc_la-preopen.lo CC libltdl/libltdl_libltdlc_la-lt__alloc.lo CC libltdl/libltdl_libltdlc_la-lt_dlloader.lo CC libltdl/libltdl_libltdlc_la-lt_error.lo CC libltdl/libltdl_libltdlc_la-ltdl.lo CC libltdl/libltdl_libltdlc_la-slist.lo CCLD libltdl/libltdlc.la ##
Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
Hi Chuck, On 26 Nov 2011, at 11:39, Charles Wilson wrote: > On 11/25/2011 4:10 AM, Gary V. Vaughan wrote: >> 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 > > a) This is a big holiday weekend in the US, so...a bit more than 72 hours is > indicated. Most of us will still be catching up on post-holiday $realjob > stuff by the time 72 hours expires. Ah, didn't think of that. Sure, I will be busy myself for a week or two, so I won't push for at least a week, probably more. > b) cygwin? mingw? msvc? All of the "old tests" have seen a LARGE number of > tweaks to ensure their proper operation on the various w32 platforms. Have > you done ANY testing there, at all, or are you relying on the rest of us to > do that work for you? I'm afraid I don't have (or want) access to any Windows machines, so I'm afraid that I am relying on you guys to tell me if I screwed up. Of course I'm not expecting you to debug or fix my mistakes for me, and I'm not anticipating any new problems, since everything is merely migrated from legacy testsuite to Autotest testsuite, with minimal changes required to keep everything working on my main machines. Although I do normally have access to more machines, the flooding in Bangkok has made any use of my Internet connection other than email intolerably slow... hence the recent flurry of work on libtool (which I can do offline, queueing emails for when my connection is next up) to fill my time while I wait for things to get back to normal. The reason I'll be too busy to do much more of that over the next week or two, is that last night I actually had a full-speed connection to the US again, so I'm anticipating playing catchup at $realjob myself. > Sorry if I seem a bit short, but I'm rather annoyed to see my queue get > filled with hours upon hours of work in the middle of a holiday. Please don't feel that it's your responsibility to painstakingly pick through every patch I post... I'd be more than happy just to get the test logs from anything I put on alpha.gnu.org for the architectures I don't use to help me restabilize the code closer to a release. Enjoy the rest of your holiday, and sorry for working so much on libtool recently: although my objective with the recent modernisations has been to try to decruft libtool a little, and to make the barrier to contribution much lower than it is currently if at all possible. I rarely have the chance to put a lot of time into libtool, and things will slow down considerably again now if my Internet connection really is back to (something like) normal again. I have another 20 or so patches left incubating in my unpublished queue, and I will be done for now after those are polished and pushed over the next month or two. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
On 11/25/2011 4:10 AM, Gary V. Vaughan wrote: 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 a) This is a big holiday weekend in the US, so...a bit more than 72 hours is indicated. Most of us will still be catching up on post-holiday $realjob stuff by the time 72 hours expires. b) cygwin? mingw? msvc? All of the "old tests" have seen a LARGE number of tweaks to ensure their proper operation on the various w32 platforms. Have you done ANY testing there, at all, or are you relying on the rest of us to do that work for you? Sorry if I seem a bit short, but I'm rather annoyed to see my queue get filled with hours upon hours of work in the middle of a holiday. -- Chuck
Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
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
Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
On 25 Nov 2011, at 18:59, Stefano Lattarini wrote: > Hi Gary. Hi Stefano, > 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. 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. >> 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 :) And thanks also for offering to make the time to look them over. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
Hi Gary. 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. > 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. But then you should allow for more than three days for sending feedback -- at least a week. Regards, Stefano
[PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
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. 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. * tests/cdemo.at: New Autotest groups, based on... * tests/cdemo-conf.test, tests/cdemo-exec.test, tests/cdemo-make.test, tests/cdemo-shared-exec.test, tests/cdemo-shared-make.test, tests/cdemo-shared.test, tests/cdemo-static-exec.test, tests/cdemo-static-make.test, tests/cdemo-static.test, tests/cdemo-undef-exec.test, tests/cdemo-undef-make.test, tests/cdemo-undef.test: ...these legacy test cases, now removed. tests/cdemo/Makefile.am, tests/cdemo/README, tests/cdemo/configure.ac, tests/cdemo/foo.c, tests/cdemo/foo.h, tests/cdemo/main.c: Remove. * configure.ac (CONF_SUBDIRS): Remove tests/cdemo. * Makefile.am: Adjust. Signed-off-by: Gary V. Vaughan --- Makefile.am | 29 +-- configure.ac |2 +- tests/cdemo-conf.test| 34 --- tests/cdemo-exec.test| 34 --- tests/cdemo-make.test| 34 --- tests/cdemo-shared-exec.test |3 - tests/cdemo-shared-make.test |3 - tests/cdemo-shared.test | 34 --- tests/cdemo-static-exec.test |3 - tests/cdemo-static-make.test |3 - tests/cdemo-static.test | 34 --- tests/cdemo-undef-exec.test |3 - tests/cdemo-undef-make.test |3 - tests/cdemo-undef.test | 49 -- tests/cdemo.at | 201 ++ tests/cdemo/.gitignore |1 - tests/cdemo/Makefile.am | 53 --- tests/cdemo/README |4 - tests/cdemo/configure.ac | 63 - tests/cdemo/foo.c| 42 - tests/cdemo/foo.h| 37 tests/cdemo/main.c | 45 -- 22 files changed, 205 insertions(+), 509 deletions(-) delete mode 100755 tests/cdemo-conf.test delete mode 100755 tests/cdemo-exec.test delete mode 100755 tests/cdemo-make.test delete mode 100755 tests/cdemo-shared-exec.test delete mode 100755 tests/cdemo-shared-make.test delete mode 100755 tests/cdemo-shared.test delete mode 100755 tests/cdemo-static-exec.test delete mode 100755 tests/cdemo-static-make.test delete mode 100755 tests/cdemo-static.test delete mode 100755 tests/cdemo-undef-exec.test delete mode 100755 tests/cdemo-undef-make.test delete mode 100755 tests/cdemo-undef.test create mode 100644 tests/cdemo.at delete mode 100644 tests/cdemo/.gitignore delete mode 100644 tests/cdemo/Makefile.am delete mode 100644 tests/cdemo/README delete mode 100644 tests/cdemo/configure.ac delete mode 100644 tests/cdemo/foo.c delete mode 100644 tests/cdemo/foo.h delete mode 100644 tests/cdemo/main.c diff --git a/Makefile.am b/Makefile.am index c55dfdd..77941ac 100644 --- a/Makefile.am +++ b/Makefile.am @@ -630,13 +630,14 @@ TESTSUITE = tests/testsuite TESTSUITE_AT = tests/testsuite.at \ tests/getopt-m4sh.at \ tests/libtoolize.at \ + tests/cdemo.at \ + tests/convenience.at \ tests/help.at \ tests/duplicate_members.at \ tests/duplicate_conv.at \ tests/duplicate_deps.at \ tests/flags.at \ tests/inherited_flags.at \ - tests/convenience.at \ tests/link-order.at \
