kmx git

Commit	Date	Message
5b44ce39	2012-02-23T13:07:57	tests: quote 'like this', not `like this', as per GCS recommendation This patch converts the automake testsuite and related files, to the use of new quoting format 'like this' or "like this" rather than `like this'. This is done for consistency with the new recommendations in the GNU Coding Standards, and, well, because I've come to actually prefer the '...' and "..." quoting formats over the `...' one. * tests/README: Update quoting format throughout. Remove some "excessive" use of quoting, and throw in minor rewording where appropriate. * tests/Makefile.am: Likewise, for comments. * tests/CheckListOfTests.am: Likewise. * tests/defs-static.in: Likewise. * tests/defs: Likewise. * tests/trivial-test-driver: Likewise. * Many tests/.tap, tests/.test and tests/.sh files: Likewise, and for the diagnostic and informational messages as well. tests/gen-testsuite-part: Likewise, and for the generated tests as well.
db973eaa	2012-02-21T19:47:36	tests: prefer 'configure.ac' over 'configure.in' With this change, our testsuite now uses 'configure.ac' as the name for the typical autoconf input, instead of the obsolescent 'configure.in' (which has been deprecated for several years, at least since autoconf 2.50). Most of the test cases changed by this commit have been automatically modified with this sed command (using GNU sed): sed -i 's/\<configure\(\\\?\)\.in\>/configure\1.ac/g' * syntax-checks.mk (sc_tests_no_configure_in): New syntax check. (syntax_check_rules): Add it. * tests/defs: Create stub for autoconf input in 'configure.ac', not in 'configure.in'. Adjust comments. ($AUTOCONF, $AUTOHEADER, $AUTORECONF): Remove workaround for the infamous debian autoconf wrapper: we don't need such workaround anymore now that we name our autoconf input as 'configure.ac'. For more information, see commit v1.11-564-g63da492 "test defs: hack to support autoconf-wrapper programs" of 16-12-2011. * tests/README: Use 'configure.ac', not 'configure.in'. * Many many tests: Likewise. * tests/backcompat3.test: Adjust to avoid spurious failures. * tests/backcompat5.test: Likewise. * tests/missing6.test: Likewise. * tests/backcompat6.test: Likewise, and extend a bit since we are at it.
641a5a4b	2012-02-16T10:46:23	maint: run "make update-copyright"
23acc630	2011-12-23T10:15:29	Merge branch 'master' into testsuite-work * tests/gettext-macros.test: In the generated `get.sh' file, use `skip_all_', not `skip_'. * tests/libtool-macros.test: Likewise. * tests/list-of-tests.mk: Update.
39e4f272	2011-12-23T00:42:24	tests: avoid spurious failure of libtool and gettext tests On Solaris 10 (and presumably earlier), /bin/sh trips up on here-documents that contains a command substitution and are fed to a shell function: # All as expected. $ cat <<END `pwd` END /home/stefano $ echo status = $? status = 0 # An apparently innocuous function ... $ kitty () { cat; } # ... but hilarity ensues! $ kitty <<END `pwd` END /tmp/sh137723: cannot open $ echo status = $? status = 1 We need to work around this misbehaviour in a couple of our tests (whose failures where causing cascading failures in a lot of other tests). * tests/gettext-macros.test: Avoid the use of command substitution in a here-document passed to the `indent' function, by using the `echo' builtin instead. * tests/libtool-macros.test: Likewise. See also: <http://lists.gnu.org/archive/html/bug-autoconf/2011-12/msg00001.html>
b7d67d55	2011-12-14T10:35:04	tests: better handling of gettext and libtool requirements This change fixes automake bug#9807. Before this change, the automake testsuite only looked for the `.m4' files containing libtool and gettext macros definitions in the directory `${prefix}/share/aclocal' (and in the directories specified by the `dirlist' file in there, if any), where ${prefix} was the configure-time automake installation prefix (defaulting to `/usr/local'). This approach had various shortcomings and disadvantages. Let's briefly describe the three major ones. First, on most GNU/Linux systems, a libtool or gettext installed from distro-provided packages (e.g., by dpkg on Debian/Ubuntu, or by rmp on RedHat/Fedora) would have `/usr', not `/usr/local', as its ${prefix}; so, trying to run the automake testsuite with a simple "./configure && make && make check" would have failed to execute the libtool and gettext tests on most GNU/Linux distros. It's true that it was quite easy to work around this issue, by creating a proper `/usr/local/share/aclocal/dirlist' file with an entry pointing to `/usr/share/aclocal' (a workaround in fact used by most automake developers); but the typical user wasn't aware of the necessity of this trick, so the libtool and gettext tests was usually skipped on testsuite runs "in the wild", thus needlessly reducing coverage. Second, the older testsuite behaviour made more difficult for the developers to run the testsuite with non-default libtool or gettext. For example, assume the developer is working on a system that has a default libtool version 1.5 installed in the /usr/local hierarchy; to improve coverage, the developer installs also a more modern libtool version, say 2.4, in its home directory, let's say in ~/libtool-2.4; he then tries to run the automake testsuite with this more modern libtool by doing an (apparently) simple: $ PATH=$HOME/libtool-2.4:$PATH make check But the automake testsuite would still look for libtool macros in /usr/local/share/aclocal, not in ~/libtool-2.4/share/aclocal, so the wrong version of the macros would be picked up, and the tests would either fail spuriously or (which would be worse) pass without truly covering the libtool version the developers was thinking to be testing with. Worse again, the automake testsuite would unconditionally look for libtool macros in /usr/local/share/aclocal, so even something like: $ export ACLOCAL_PATH=$HOME/libtool-2.4/share/aclocal $ PATH=$HOME/libtool-2.4:$PATH make check wouldn't work. Third and last, during a "make distcheck", automake is configured with a ${prefix} pointing to a proper subdirectory of the build directory (usually `pwd`/_inst), which gets created on-the-fly; in this case, with the old approach, the automake testsuite never found the libtool and gettext macro files, ans so the libtool and gettext tests was always skipped in a "make distcheck". * tests/libtool-macros.test: New helper test, looking (with the help of the `libtoolize' script) for libtool macro files required by most libtool tests, and making them easily accessible. * tests/gettext-macros.test: New helper test, looking (with the help of the `libtoolize' script) for libtool macro files required by most libtool tests, and making them easily accessible. * tests/defs.in: Update to make it rely on the results and setups of `libtool-macros.test' and `gettext-macros.test'. * tests/Makefile.am: Declare dependency of all the logs of libtool tests from `libtool-macros.log', and all the logs of gettext tests from `gettext-macros.log'. (TESTS): Add the new tests.

5b44ce39

2012-02-23T13:07:57

tests: quote 'like this', not `like this', as per GCS recommendation This patch converts the automake testsuite and related files, to the use of new quoting format 'like this' or "like this" rather than `like this'. This is done for consistency with the new recommendations in the GNU Coding Standards, and, well, because I've come to actually prefer the '...' and "..." quoting formats over the `...' one. * tests/README: Update quoting format throughout. Remove some "excessive" use of quoting, and throw in minor rewording where appropriate. * tests/Makefile.am: Likewise, for comments. * tests/CheckListOfTests.am: Likewise. * tests/defs-static.in: Likewise. * tests/defs: Likewise. * tests/trivial-test-driver: Likewise. * Many tests/*.tap, tests/*.test and tests/*.sh files: Likewise, and for the diagnostic and informational messages as well. * tests/gen-testsuite-part: Likewise, and for the generated tests as well.

db973eaa

2012-02-21T19:47:36

tests: prefer 'configure.ac' over 'configure.in' With this change, our testsuite now uses 'configure.ac' as the name for the typical autoconf input, instead of the obsolescent 'configure.in' (which has been deprecated for several years, at least since autoconf 2.50). Most of the test cases changed by this commit have been automatically modified with this sed command (using GNU sed): sed -i 's/\<configure$\\\?$\.in\>/configure\1.ac/g' * syntax-checks.mk (sc_tests_no_configure_in): New syntax check. (syntax_check_rules): Add it. * tests/defs: Create stub for autoconf input in 'configure.ac', not in 'configure.in'. Adjust comments. ($AUTOCONF, $AUTOHEADER, $AUTORECONF): Remove workaround for the infamous debian autoconf wrapper: we don't need such workaround anymore now that we name our autoconf input as 'configure.ac'. For more information, see commit v1.11-564-g63da492 "test defs: hack to support autoconf-wrapper programs" of 16-12-2011. * tests/README: Use 'configure.ac', not 'configure.in'. * Many many tests: Likewise. * tests/backcompat3.test: Adjust to avoid spurious failures. * tests/backcompat5.test: Likewise. * tests/missing6.test: Likewise. * tests/backcompat6.test: Likewise, and extend a bit since we are at it.

641a5a4b

2012-02-16T10:46:23

maint: run "make update-copyright"

23acc630

2011-12-23T10:15:29

Merge branch 'master' into testsuite-work * tests/gettext-macros.test: In the generated `get.sh' file, use `skip_all_', not `skip_'. * tests/libtool-macros.test: Likewise. * tests/list-of-tests.mk: Update.

39e4f272

2011-12-23T00:42:24

tests: avoid spurious failure of libtool and gettext tests On Solaris 10 (and presumably earlier), /bin/sh trips up on here-documents that contains a command substitution *and* are fed to a shell function: # All as expected. $ cat <<END `pwd` END /home/stefano $ echo status = $? status = 0 # An apparently innocuous function ... $ kitty () { cat; } # ... but hilarity ensues! $ kitty <<END `pwd` END /tmp/sh137723: cannot open $ echo status = $? status = 1 We need to work around this misbehaviour in a couple of our tests (whose failures where causing cascading failures in a lot of other tests). * tests/gettext-macros.test: Avoid the use of command substitution in a here-document passed to the `indent' function, by using the `echo' builtin instead. * tests/libtool-macros.test: Likewise. See also: <http://lists.gnu.org/archive/html/bug-autoconf/2011-12/msg00001.html>

b7d67d55

2011-12-14T10:35:04

tests: better handling of gettext and libtool requirements This change fixes automake bug#9807. Before this change, the automake testsuite only looked for the `.m4' files containing libtool and gettext macros definitions in the directory `${prefix}/share/aclocal' (and in the directories specified by the `dirlist' file in there, if any), where ${prefix} was the configure-time automake installation prefix (defaulting to `/usr/local'). This approach had various shortcomings and disadvantages. Let's briefly describe the three major ones. First, on most GNU/Linux systems, a libtool or gettext installed from distro-provided packages (e.g., by dpkg on Debian/Ubuntu, or by rmp on RedHat/Fedora) would have `/usr', not `/usr/local', as its ${prefix}; so, trying to run the automake testsuite with a simple "./configure && make && make check" would have failed to execute the libtool and gettext tests on most GNU/Linux distros. It's true that it was quite easy to work around this issue, by creating a proper `/usr/local/share/aclocal/dirlist' file with an entry pointing to `/usr/share/aclocal' (a workaround in fact used by most automake developers); but the typical user wasn't aware of the necessity of this trick, so the libtool and gettext tests was usually skipped on testsuite runs "in the wild", thus needlessly reducing coverage. Second, the older testsuite behaviour made more difficult for the developers to run the testsuite with non-default libtool or gettext. For example, assume the developer is working on a system that has a default libtool version 1.5 installed in the /usr/local hierarchy; to improve coverage, the developer installs also a more modern libtool version, say 2.4, in its home directory, let's say in ~/libtool-2.4; he then tries to run the automake testsuite with this more modern libtool by doing an (apparently) simple: $ PATH=$HOME/libtool-2.4:$PATH make check But the automake testsuite would still look for libtool macros in /usr/local/share/aclocal, not in ~/libtool-2.4/share/aclocal, so the wrong version of the macros would be picked up, and the tests would either fail spuriously or (which would be worse) pass without truly covering the libtool version the developers was thinking to be testing with. Worse again, the automake testsuite would *unconditionally* look for libtool macros in /usr/local/share/aclocal, so even something like: $ export ACLOCAL_PATH=$HOME/libtool-2.4/share/aclocal $ PATH=$HOME/libtool-2.4:$PATH make check wouldn't work. Third and last, during a "make distcheck", automake is configured with a ${prefix} pointing to a proper subdirectory of the build directory (usually `pwd`/_inst), which gets created on-the-fly; in this case, with the old approach, the automake testsuite never found the libtool and gettext macro files, ans so the libtool and gettext tests was *always* skipped in a "make distcheck". * tests/libtool-macros.test: New helper test, looking (with the help of the `libtoolize' script) for libtool macro files required by most libtool tests, and making them easily accessible. * tests/gettext-macros.test: New helper test, looking (with the help of the `libtoolize' script) for libtool macro files required by most libtool tests, and making them easily accessible. * tests/defs.in: Update to make it rely on the results and setups of `libtool-macros.test' and `gettext-macros.test'. * tests/Makefile.am: Declare dependency of all the logs of libtool tests from `libtool-macros.log', and all the logs of gettext tests from `gettext-macros.log'. (TESTS): Add the new tests.

kc3-lang/automake/tests/libtool-macros.test

tests/libtool-macros.test

Log