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.
ea441902	2012-02-16T20:49:43	depcomp tests: fix up today's botched commit Today's commit 'v1.11-1959-g0699a84' has caused the generated 'depcomp.tap' tests to call the 'plan_' function before* it is defined, and has also caused the extra checks required for better libtool coverage to be run only when libtool is not in use, rather than the other way around. Fix this mess. Report by Peter Rosin. * tests/gen-testsuite-part: Include './defs' in the generated tests, rather than doing so from 'depcomp.sh'. Adjust the count of TAP tests for 'depcomp-lt-auto.test' (it's 84, not 72). * tests/depcomp.sh: Adjust accordingly, and fix inverted logic about the decision of when to run extra checks for libtool.
0699a84a	2012-02-16T19:08:58	depcomp tests: put TAP plan in generated tests This avoids a spurious maintcheck failure, and also simplifies the 'depcomp.sh' helper script a little. * tests/gen-testsuite-part: Create and place also a proper 'plan_' call (to emit the TAP plan) in each generated 'depmod.tap' test. tests/depcomp.sh: Remove 'plan_' invocations, and simplify a little since we are at it.
4933232e	2012-02-14T02:56:39	depcomp tests: do not specify LDFLAGS for static libraries Commit v1.11-1848-gb3f34ca accidentally specified LDFLAGS for libbaz even when built as a static library, which is not allowed. * tests/depcomp.sh (src/Makefile.am): Don't add any LDFLAGS when libbaz is built as a static library.
2c430b16	2012-02-14T02:51:55	depcomp tests: avoid redundant runs for non-libtool test When running the dependency tests without libtool, it's not meaningful to run the tests three-fold, the libtool configure options are simply ignored anyway. * tests/depcomp.sh: Only run the tests three-fold when libtool is in use.
b3f34caa	2012-02-13T21:21:48	tests: increase coverage for depcomp tests On platforms requiring that no undefined symbols exist in order to build shared libraries (e.g. Windows DLLs), you have to explicitly declare that the libtool library you are building does not actually have any undefined symbols, for libtool to even try to build it as a shared library. Without that explicit declaration, libtool falls back to a static library only, regardless of any --enable-shared flags etc. tests/depcomp.sh (Makefile.am): Add -no-undefined if a libtool library (.la) is built. (src/Makefile.am): Likewise.
19bab325	2012-02-08T13:21:58	depcomp tests: avoid redundant runs for libtool tests When running libtool-oriented tests, our 'depcomp.sh' script used to run the same checks thrice: once after having run configure with the '--disable-shared' option, once after having run it with the '--enable-shared' option, and once by allowing configure to automatically select which kind of library (or libraries) to build. This was done to offer extra coverage for the less-common depmodes (like "aix" of "hp2") where the name of the compiler-generated depfiles can depend on whether libtool is in use and on which kind of libraries libtool is building (static, shared, or both). About this, see commit 'Release-1-10-24-ge89ec38' of 28-03-2007, "* lib/depcomp (aix): Rewrite depmode in the spirit of the tru64 one". But that extra coverage came at the price of considerably slowing down the depcomp libtool-oriented tests, since for each of them the tested source tree was configured and built twelve times (rather than "just" four as it is for the non-libtool case). So, to strike a balance between coverage and speed, we now run the libtool-oriented tests with the three different configuration modes only when it is possible that the depmode that will get selected is one of those which can actually benefit from the extra coverage. * tests/depcomp.sh: Adjust to only run the threefold libtool tests when that can truly be potentially useful. Add related explanatory comments.
5066c1b5	2012-02-03T15:05:48	tests: improve and rework tests on dependency tracking Fixes automake bug#10434. Suggestion by Peter Rosin. The 'depcomp.tap' test case worked by trying to unconditionally force the compiler in use by the testsuite to use, one by one, all the dependency modes known by the 'depcomp' script, and, for each such forced mode that was compatible enough with said compiler not to cause breakage in the basic compilation rules, checking that it was also good enough not to break remake rules in VPATH builds. This seemed a good approach when this test was first introduced, as it apparently increased coverage for the less used and less tested dependency-tracking modes. But in the log run it turned out the approach was actually in part too brittle, causing some annoying spurious failures (as with the Tru64 depmode forced on GCC, see automake bug#10434), and partly too forgiving, since, for some of the more corner-case dependency modes, the 'depcomp' script simply reverts to silently disabling dependency tracking when an error is encountered (this happened e.g., with the Tru64 depmode forced on the Sun C compiler 5.9), so that a passing test means nothing, and only gives a false sense of security. As Peter Rosin put it, "it's just dead wrong to assume that feeding -M or -xM to the compiler (or whatever other random stuff 'depcomp' might do) and not get an error is the same as dependencies magically appearing". So we get rid of this wrong approach, and in the process proceed to a complete overhaul of many of the tests on automatic dependency tracking, extending the offered coverage and rationalizing their organization. * tests/depcomp.sh: New helper script, used by several new autogenerated tests. * tests/gen-testsuite-part: Generate several tests based on the new 'depcomp.sh' script. Emit makefile code that declares their dependency on that script, and that extends EXTRA_DIST in order to distribute it. * tests/depmod.tap: Remove. * tests/depend2.test: Remove, it has been subsumed by the new autogenerated test 'depcomp-disabled.tap'. * tests/depcomp3.test: Remove, it has been subsumed by the new autogenerated test 'depmod-dashmstdout.tap'. * tests/depcomp3.test: Remove, it has been subsumed by the new autogenerated test 'depmod-lt-makedepend.tap'. * tests/depcomp6.test: Remove, it has been subsumed by the new autogenerated test 'depmod-auto.tap'. * tests/depcomp7.test: Remove, it has been subsumed by the new autogenerated test 'depmod-lt-auto.tap'. * tests/depcomp5.test: Remove as obsolescent. * test/list-of-tests.mk: Adjust. * .gitignore: List the new autogenerated 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.

ea441902

2012-02-16T20:49:43

depcomp tests: fix up today's botched commit Today's commit 'v1.11-1959-g0699a84' has caused the generated 'depcomp*.tap' tests to call the 'plan_' function *before* it is defined, and has also caused the extra checks required for better libtool coverage to be run only when libtool is *not* in use, rather than the other way around. Fix this mess. Report by Peter Rosin. * tests/gen-testsuite-part: Include './defs' in the generated tests, rather than doing so from 'depcomp.sh'. Adjust the count of TAP tests for 'depcomp-lt-auto.test' (it's 84, not 72). * tests/depcomp.sh: Adjust accordingly, and fix inverted logic about the decision of when to run extra checks for libtool.

0699a84a

2012-02-16T19:08:58

depcomp tests: put TAP plan in generated tests This avoids a spurious maintcheck failure, and also simplifies the 'depcomp.sh' helper script a little. * tests/gen-testsuite-part: Create and place also a proper 'plan_' call (to emit the TAP plan) in each generated 'depmod*.tap' test. * tests/depcomp.sh: Remove 'plan_' invocations, and simplify a little since we are at it.

4933232e

2012-02-14T02:56:39

depcomp tests: do not specify LDFLAGS for static libraries Commit v1.11-1848-gb3f34ca accidentally specified LDFLAGS for libbaz even when built as a static library, which is not allowed. * tests/depcomp.sh (src/Makefile.am): Don't add any LDFLAGS when libbaz is built as a static library.

2c430b16

2012-02-14T02:51:55

depcomp tests: avoid redundant runs for non-libtool test When running the dependency tests without libtool, it's not meaningful to run the tests three-fold, the libtool configure options are simply ignored anyway. * tests/depcomp.sh: Only run the tests three-fold when libtool is in use.

b3f34caa

2012-02-13T21:21:48

tests: increase coverage for depcomp tests On platforms requiring that no undefined symbols exist in order to build shared libraries (e.g. Windows DLLs), you have to explicitly declare that the libtool library you are building does not actually have any undefined symbols, for libtool to even try to build it as a shared library. Without that explicit declaration, libtool falls back to a static library only, regardless of any --enable-shared flags etc. tests/depcomp.sh (Makefile.am): Add -no-undefined if a libtool library (.la) is built. (src/Makefile.am): Likewise.

19bab325

2012-02-08T13:21:58

depcomp tests: avoid redundant runs for libtool tests When running libtool-oriented tests, our 'depcomp.sh' script used to run the same checks thrice: once after having run configure with the '--disable-shared' option, once after having run it with the '--enable-shared' option, and once by allowing configure to automatically select which kind of library (or libraries) to build. This was done to offer extra coverage for the less-common depmodes (like "aix" of "hp2") where the name of the compiler-generated depfiles can depend on whether libtool is in use *and* on which kind of libraries libtool is building (static, shared, or both). About this, see commit 'Release-1-10-24-ge89ec38' of 28-03-2007, "* lib/depcomp (aix): Rewrite depmode in the spirit of the tru64 one". But that extra coverage came at the price of *considerably* slowing down the depcomp libtool-oriented tests, since for each of them the tested source tree was configured and built *twelve* times (rather than "just" four as it is for the non-libtool case). So, to strike a balance between coverage and speed, we now run the libtool-oriented tests with the three different configuration modes *only* when it is possible that the depmode that will get selected is one of those which can actually benefit from the extra coverage. * tests/depcomp.sh: Adjust to only run the threefold libtool tests when that can truly be potentially useful. Add related explanatory comments.

5066c1b5

2012-02-03T15:05:48

tests: improve and rework tests on dependency tracking Fixes automake bug#10434. Suggestion by Peter Rosin. The 'depcomp.tap' test case worked by trying to unconditionally force the compiler in use by the testsuite to use, one by one, *all* the dependency modes known by the 'depcomp' script, and, for each such forced mode that was compatible enough with said compiler not to cause breakage in the basic compilation rules, checking that it was *also* good enough not to break remake rules in VPATH builds. This seemed a good approach when this test was first introduced, as it apparently increased coverage for the less used and less tested dependency-tracking modes. But in the log run it turned out the approach was actually in part too brittle, causing some annoying spurious failures (as with the Tru64 depmode forced on GCC, see automake bug#10434), and partly too forgiving, since, for some of the more corner-case dependency modes, the 'depcomp' script simply reverts to silently disabling dependency tracking when an error is encountered (this happened e.g., with the Tru64 depmode forced on the Sun C compiler 5.9), so that a passing test means nothing, and only gives a false sense of security. As Peter Rosin put it, "it's just dead wrong to assume that feeding -M or -xM to the compiler (or whatever other random stuff 'depcomp' might do) and not get an error is the same as dependencies magically appearing". So we get rid of this wrong approach, and in the process proceed to a complete overhaul of many of the tests on automatic dependency tracking, extending the offered coverage and rationalizing their organization. * tests/depcomp.sh: New helper script, used by several new autogenerated tests. * tests/gen-testsuite-part: Generate several tests based on the new 'depcomp.sh' script. Emit makefile code that declares their dependency on that script, and that extends EXTRA_DIST in order to distribute it. * tests/depmod.tap: Remove. * tests/depend2.test: Remove, it has been subsumed by the new autogenerated test 'depcomp-disabled.tap'. * tests/depcomp3.test: Remove, it has been subsumed by the new autogenerated test 'depmod-dashmstdout.tap'. * tests/depcomp3.test: Remove, it has been subsumed by the new autogenerated test 'depmod-lt-makedepend.tap'. * tests/depcomp6.test: Remove, it has been subsumed by the new autogenerated test 'depmod-auto.tap'. * tests/depcomp7.test: Remove, it has been subsumed by the new autogenerated test 'depmod-lt-auto.tap'. * tests/depcomp5.test: Remove as obsolescent. * test/list-of-tests.mk: Adjust. * .gitignore: List the new autogenerated tests.

kc3-lang/automake/tests/depcomp.sh

tests/depcomp.sh

Log