I've been using autoconf + autotest + automake for a few projects, and I've run into an issue with a build-time dependency upon autoconf when generating the testsuite. Currently I use a host with recent versions of autoconf (2.65) and automake (1.11.1) installed to regenerate the configure and Makefile.in heirarchy for the project using 'autoreconf'. The results of this is committed back to our CVS repo. We then build the software on other systems which often have an older version of autoconf (e.g, the vendor provided 2.59 on CentOS 5). This has caused us problems where we've unintentionally used autotest features & fixes in 2.65 not present in 2.59 (e.g, AT_CHECK_UNQUOTED, and a working 'testsuite -k kw1 -k kw2 -k kw3', which doesn't work on testsuites generated by 2.59). I would like to extend the procedure of using autoreconf on our "maintainer system" to regenerate tests/testsuite to be committed along with configure & **/Makefile.in, so that we don't need or use need autoconf on our "build and test systems". Is there a good pattern for doing this? Our method of creating the testsuite is similar to section 19.4 of the current autoconf manual, except that we generate testsuite in $(builddir) not $(srcdir). Even after converting to use $(srcdir), we're still stuck with something like the following to regenerate the configure & testsuite: autoreconf mkdir scratch && cd scratch ../configure cd tests && make testsuite cd ../.. thanks, Luke.
Attachment:
pgpD6pZkNM8gI.pgp
Description: PGP signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
