bug#7403: Unused variable `$source' in the depcomp script?
Hello automakers. In the git master branch: $ grep '\source\' lib/depcomp source Source file read by `PROGRAMS ARGS'. if test -z $depmode || test -z $source || test -z $object; then echo depcomp: Variables source, object and depmode must be set 12 # the object too, otherwise makedepend will parse it as a source file. Does this mean that the `$source' variable is really not required by depcomp, or am I missing something? Regards, Stefano
Re: User extensions
Hello Pippijn. On Saturday 13 November 2010, Pippijn van wrote: On Mon, Nov 01, 2010 at 08:18:44PM +0100, Ralf Wildenhues wrote: Ideally, I would like to see testsuite coverage for each code path (branch coverage) for new code. I understand that only Stefano is able to produce this in reasonable amount of time, so whatever you guys can manage is better than nothing. Hi, not having followed the code discussion very closely (just hoping it will be in git, soon, so I can start using it, as I have been waiting for something like this for a long time), I just wonder what you mean by branch coverage. If this is execution graph node coverage, then I agree, but if you mean edge coverage, I don't know how you want to achieve this. Any O(x) where x1 algorithm anywhere in the code makes it impossible. If I'm wrong, I'd like to know how Stefano produces it. Well, basically by hand. I think that Ralf was just saying that, since I'm familiar with the automake testsuite and interested in extending it, since I presently have definitely more time to do so than Ralf has, and, above all, since there's no other regular contributor to automake ATM, if someone is able to add proper testing for the new feature, that's either me or the original contributor of the feature (Valentin David). But it's not like I have a silver bullet to write proper tests which attain complete branch coverage; I just proceed by common sense, trying to maximize such coverage. That's all, sadly. Regards, Stefano
[PATCH] {master} Extend and improve tests on DejaGnu support.
Another testsuite patch, based off of maint, but to be merged in master only. I will wait the customary 72 hours before pushing. Regards, Stefano -*-*-*- Extend and improve tests on DejaGnu support. * tests/dejagnu.test: Do not create useless dummy test script. Add trailing `:' command. In heading comments, add reference to ... * tests/check12.test: ... this new semantic test, covering concurrent use of dejagnu tests, simple tests and `check-local' target. * tests/dejagnu2.test: Make test more reliable, by avoid weak grepping of make output. Prefer `cat' over `echo' to append to configure.in. Quote literal dots in grep regexps. Prefer `grep -c ...' over `grep ... | wc -l'. Make grepping of automake stderr slighty stricter. Add trailing `:' command. * tests/dejagnu3.test: Prefer `cat' over `echo' to append to configure.in. Check stderr of expected-to-fail make call. Remove extra blank lines from Makefile.am. * tests/dejagnu4.test: Prefer `cat' over `echo' to append to configure.in. Prefer `mv -f' over plain `mv' when the target file already exists. Avoid extra mkdir calls by creating more directories at once. Better use of blank lines. Check that the `*.log' and `*.sum' files are created by runtest also when make check fails. * tests/dejagnu7.test: Prefer `cat' over `echo' to append to configure.in. Better use of blank lines. Add a trailing `:' command. * tests/dejagnu6.test: Likewise, and give the dejagnu test a more descriptive name. * tests/dejagnu5.test: Likewise. Also, simply define package name to `$me' rather than using a non-obvious sed script to extract it from `AC_INIT', and write the Makefile.am with only one command. * tests/Makefile.am (TESTS): Updated. --- ChangeLog | 34 + tests/Makefile.am |1 + tests/Makefile.in |2 + tests/check12.test | 201 +++ tests/dejagnu.test |7 +- tests/dejagnu2.test | 21 +++--- tests/dejagnu3.test | 17 +++-- tests/dejagnu4.test | 19 +++-- tests/dejagnu5.test | 19 +++--- tests/dejagnu6.test | 16 ++-- tests/dejagnu7.test | 10 ++-- 11 files changed, 298 insertions(+), 49 deletions(-) create mode 100755 tests/check12.test From 39ab915725c5eb5fe055dd3e09116982b1abcce1 Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sat, 16 Oct 2010 17:03:03 +0200 Subject: [PATCH] Extend and improve tests on DejaGnu support. * tests/dejagnu.test: Do not create useless dummy test script. Add trailing `:' command. In heading comments, add reference to ... * tests/check12.test: ... this new semantic test, covering concurrent use of dejagnu tests, simple tests and `check-local' target. * tests/dejagnu2.test: Make test more reliable, by avoid weak grepping of make output. Prefer `cat' over `echo' to append to configure.in. Quote literal dots in grep regexps. Prefer `grep -c ...' over `grep ... | wc -l'. Make grepping of automake stderr slighty stricter. Add trailing `:' command. * tests/dejagnu3.test: Prefer `cat' over `echo' to append to configure.in. Check stderr of expected-to-fail make call. Remove extra blank lines from Makefile.am. * tests/dejagnu4.test: Prefer `cat' over `echo' to append to configure.in. Prefer `mv -f' over plain `mv' when the target file already exists. Avoid extra mkdir calls by creating more directories at once. Better use of blank lines. Check that the `*.log' and `*.sum' files are created by runtest also when make check fails. * tests/dejagnu7.test: Prefer `cat' over `echo' to append to configure.in. Better use of blank lines. Add a trailing `:' command. * tests/dejagnu6.test: Likewise, and give the dejagnu test a more descriptive name. * tests/dejagnu5.test: Likewise. Also, simply define package name to `$me' rather than using a non-obvious sed script to extract it from `AC_INIT', and write the Makefile.am with only one command. * tests/Makefile.am (TESTS): Updated. --- ChangeLog | 34 + tests/Makefile.am |1 + tests/Makefile.in |2 + tests/check12.test | 201 +++ tests/dejagnu.test |7 +- tests/dejagnu2.test | 21 +++--- tests/dejagnu3.test | 17 +++-- tests/dejagnu4.test | 19 +++-- tests/dejagnu5.test | 19 +++--- tests/dejagnu6.test | 16 ++-- tests/dejagnu7.test | 10 ++-- 11 files changed, 298 insertions(+), 49 deletions(-) create mode 100755 tests/check12.test diff --git a/ChangeLog b/ChangeLog index a356958..4fd15f1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,37 @@ +2010-11-14 Stefano Lattarini stefano.lattar...@gmail.com + + Extend and improve tests on DejaGnu support. + * tests/dejagnu.test: Do not create useless dummy test script. + Add trailing `:' command. In heading comments, add reference + to ... + * tests/check12.test: ... this new semantic test, covering + concurrent use of dejagnu tests, simple tests and `check-local' + target. + * tests/dejagnu2.test: Make
Re: User extensions
* Stefano Lattarini wrote on Sun, Nov 14, 2010 at 01:36:16PM CET: But it's not like I have a silver bullet to write proper tests which attain complete branch coverage; I just proceed by common sense, trying to maximize such coverage. That's all, sadly. A while ago I posted instructions on how to generate coverage information for the perl parts of Automake, including results: http://thread.gmane.org/gmane.comp.sysutils.automake.general/11088 That doesn't help for shell or makefile snippets, but it's a whole lot better than nothing. Cheers, Ralf
Re: User extensions
On Sunday 14 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sun, Nov 14, 2010 at 01:36:16PM CET: But it's not like I have a silver bullet to write proper tests which attain complete branch coverage; I just proceed by common sense, trying to maximize such coverage. That's all, sadly. A while ago I posted instructions on how to generate coverage information for the perl parts of Automake, including results: http://thread.gmane.org/gmane.comp.sysutils.automake.general/11088 Interesting. Somehow I missed (or I forgot) that. Thanks for the reminder. That doesn't help for shell or makefile snippets, but it's a whole lot better than nothing. Cheers, Ralf Regards, Stefano
Re: [PATCH 2/3] aclocal: remove @automake_includes
Hi Paolo, * Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:39PM CET: This patch simplifies the overly complicated rules for ACLOCAL_PATH vs. @automake_includes and @system_includes, by stating that ACLOCAL_PATH will override even @automake_includes. The simplest way to achieve this is to remove @automake_includes altogether. I've read the previous discussion about this now, but I'm still not sure I understand the rationale for this change. Is it because you want to actually be able to override the $(datadir)/aclocal-$VERSION files with this variable? If so, why? I guess in that case it would be good to have another test to ensure that this happens, and is intentional. If the only reason is that --acdir doesn't accurately reflect what would happen after 'make install', maybe we can instead fix --acdir? The other changes in this patch seem fairly benign to me. I'm not sure if you stated whether the testsuite passes for you with this patch series. Thanks, Ralf * NEWS: Adapt to change in ACLOCAL_PATH semantics. * aclocal.in (default_automake_dir): New. (scan_file): Use it to distinguish FT_AUTOMAKE from FT_SYSTEM. (automake_includes): Remove. (scan_m4_files): Do not scan it. (have_ac_dir): New. (parse_arguments): Set it for --acdir instead of automake_includes, use it to determine whether to filter absent directories out of @system_includes. Allow 1 directory in @system_includes for --print-ac-dir. * doc/automake.texi: Adapt to changes in ACLOCAL_PATH semantics. * tests/acloca25.test: Likewise.
tests: work around dash quoting issue in case statements.
Apparently, dash 0.5.5.1 has some problems with avoiding expansion in case patterns when unusual characters are involved. I'm committing the following patch to maint to let these tests PASS instead of SKIP with this shell. Thanks, Ralf tests: work around dash quoting issue in case statements. * tests/color.test, tests/color2.test: Quote variable in case pattern, to avoid skipping tests with dash 0.5.5.1. diff --git a/tests/color.test b/tests/color.test index 9d86785..c1032fd 100755 --- a/tests/color.test +++ b/tests/color.test @@ -34,7 +34,7 @@ std='[m' # BSD 'grep' works from a pipe, but not a seekable file. # GNU or BSD 'grep -a' works on files, but is not portable. case `echo $std | grep .` in - $std) ;; + $std) ;; *) echo $me: grep can't parse nonprinting characters 2; Exit 77;; esac diff --git a/tests/color2.test b/tests/color2.test index eedd37d..306aa04 100755 --- a/tests/color2.test +++ b/tests/color2.test @@ -34,7 +34,7 @@ std='[m' # BSD 'grep' works from a pipe, but not a seekable file. # GNU or BSD 'grep -a' works on files, but is not portable. case `echo $std | grep .` in - $std) ;; + $std) ;; *) echo $me: grep can't parse nonprinting characters 2; Exit 77;; esac
Re: Fix install-strip when $(STRIP) contains several words.
* Ralf Wildenhues wrote on Mon, Nov 01, 2010 at 10:25:02PM CET: Fix install-strip when $(STRIP) contains several words. * lib/am/install.am (install-strip): Update comment. Use separate sub-make invocations for empty and nonempty $(STRIP), to fix quoting issues. * tests/strip2.test, tests/strip3.test: New tests. * tests/Makefile.am (TESTS): Adjust. Committing this to maint now. Cheers, Ralf
Re: [PATCH 2/3] aclocal: remove @automake_includes
On 11/14/2010 05:46 PM, Ralf Wildenhues wrote: Hi Paolo, * Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:39PM CET: This patch simplifies the overly complicated rules for ACLOCAL_PATH vs. @automake_includes and @system_includes, by stating that ACLOCAL_PATH will override even @automake_includes. The simplest way to achieve this is to remove @automake_includes altogether. I've read the previous discussion about this now, but I'm still not sure I understand the rationale for this change. Is it because you want to actually be able to override the $(datadir)/aclocal-$VERSION files with this variable? If so, why? I don't really need to override the files, it's just to simplify the semantics and make ACLOCAL_PATH between -I and the system variables. If the only reason is that --acdir doesn't accurately reflect what would happen after 'make install', maybe we can instead fix --acdir? That's not a problem, during the testsuite it is safer to operate as if $(datadir)/aclocal is empty, and --acdir achieves that. So I think --acdir is fine. If you would prefer to fix --acdir, it would be in theory possible to make --acdir change @automake_includes and empty @system_includes instead. However, before going on, I might be missing something. Google code search shows a relatively large amount of strange uses of --acdir, even in projects using relatively recent Autoconf (like 1.9.x). I'm not sure how they work; for example: acdir = m4 @ma...@aclocal-files: configure.in @MAINT@ echo 'acfiles = \' $...@-tmp @MAINT@ find $(acdir) -type f -name '*.m4' -print \ @MAINT@ | sed 's!^!$(top_srcdir)/!' \ @MAINT@ | tr '\012' ' ' \ @MAINT@$...@-tmp @MAINT@ echo $...@-tmp @MAINT@ mv $...@-tmp $@ @ma...@include aclocal-files @ma...@# Override default rule to use --acdir option @ma...@$(srcdir)/aclocal.m4: configure.in $(acfiles) @MAINT@ cd $(srcdir) aclocal --acdir=$(acdir) How can this work, wouldn't it miss all the internal Automake macros? I'm not sure if you stated whether the testsuite passes for you with this patch series. Yes, it works. Paolo
Rebuild menus in the manual.
I'm committing this to maint, and merging to branch-1.11 and master.
Thanks,
Ralf
Rebuild menus in the manual.
* doc/automake.texi: Rebuild menus (using ^C ^U ^A in emacs).
Thanks to Ian Lance Taylor for the suggestion.
diff --git a/doc/automake.texi b/doc/automake.texi
index 79f3f5a..5a805b3 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -164,8 +164,8 @@ Top
* General Operation:: General operation of Automake
* Strictness:: Standards conformance checking
* Uniform:: The Uniform Naming Scheme
-* Canonicalization::How derived variables are named
* Length Limitations:: Staying below the command line length limit
+* Canonicalization::How derived variables are named
* User Variables:: Variables reserved for the user
* Auxiliary Programs:: Programs automake might require
@@ -239,7 +239,7 @@ Top
* Program Sources:: Defining program sources
* Linking:: Linking with libraries or extra objects
* Conditional Sources:: Handling conditional sources
-* Conditional Programs::Building program conditionally
+* Conditional Programs::Building a program conditionally
Building a Shared Library
@@ -253,6 +253,11 @@ Top
* LTLIBOBJS:: Using $(LTLIBOBJS) and $(LTALLOCA)
* Libtool Issues:: Common Issues Related to Libtool's Use
+Common Issues Related to Libtool's Use
+
+* Error required file ltmain.sh not found:: The need to run libtoolize
+* Objects created both with libtool and without:: Avoid a specific build race
+
Fortran 77 Support
* Preprocessing Fortran 77::Preprocessing Fortran 77 sources
@@ -291,7 +296,7 @@ Top
* Texinfo:: Texinfo
* Man Pages:: Man pages
-Installation
+What Gets Installed
* Basics of Installation:: What gets installed where
* The Two Parts of Install::Installing data and programs separately
@@ -299,7 +304,7 @@ Top
* Staged Installs:: Installation in a temporary location
* Install Rules for the User:: Useful additional rules
-Distribution
+What Goes in a Distribution
* Basics of Distribution:: Files distributed by default
* Fine-grained Distribution Control:: @code{dist_} and @code{nodist_} prefixes
@@ -307,7 +312,7 @@ Top
* Checking the Distribution:: @samp{make distcheck} explained
* The Types of Distributions:: A variety of formats and compression methods
-Support for Test Suites
+Support for test suites
* Simple Tests::Listing programs and scripts in @code{TESTS}
* Simple Tests using parallel-tests:: More powerful test driver
@@ -351,12 +356,12 @@ Top
* Dependency Tracking Evolution:: Evolution of Automatic Dependency Tracking
* Releases::Statistics about Automake Releases
-Dependency Tracking Evolution
+Dependency Tracking in Automake
* First Take on Dependencies:: Precomputed dependency tracking
* Dependencies As Side Effects:: Update at developer compile time
* Dependencies for the User:: Update at user compile time
-* Techniques for Dependencies:: Alternative approaches
+* Techniques for Dependencies:: Alternative approaches
* Recommendations for Tool Writers:: What tool writers can do to help
* Future Directions for Dependencies:: Languages Automake does not know
@@ -1742,8 +1747,8 @@ Generalities
* General Operation:: General operation of Automake
* Strictness:: Standards conformance checking
* Uniform:: The Uniform Naming Scheme
-* Canonicalization::How derived variables are named
* Length Limitations:: Staying below the command line length limit
+* Canonicalization::How derived variables are named
* User Variables:: Variables reserved for the user
* Auxiliary Programs:: Programs automake might require
@end menu
@@ -5370,8 +5375,8 @@ Libtool Issues
@subsection Common Issues Related to Libtool's Use
@menu
-* Error required file ltmain.sh not found:: The need to run libtoolize
-* Objects created both with libtool and without:: Avoid a specific build race
+* Error required file ltmain.sh not found:: The need to run libtoolize
+* Objects created both with libtool and without:: Avoid a specific build race
@end menu
@node Error required file ltmain.sh not found
@@ -12558,7 +12563,7 @@ Dependency Tracking Evolution
* First Take on Dependencies:: Precomputed dependency tracking
* Dependencies As Side Effects:: Update at developer compile time
* Dependencies for the User:: Update at user compile time
-* Techniques for Dependencies:: Alternative approaches
+* Techniques for Dependencies:: Alternative approaches
* Recommendations for Tool Writers:: What tool writers can do to help
* Future Directions for Dependencies:: Languages Automake does not know
@end menu
Re: [PATCH] {maint} Improve and extend tests on de-ansification support.
Hi Stefano, * Stefano Lattarini wrote on Mon, Sep 13, 2010 at 10:59:22AM CEST: But since we are at it, we can do better, extending coverage and making existing tests more semantic. See the attached patch (for maint). ansi2knr is a really dying (and ugly) feature; when have we last seen a compiler that does not support C89? I'm not sure if it's time to deprecate it yet, but it is definitely not worth putting a lot of effort into. That said, I did a review of this patch; please read it and apply it to other testsuite patches. I don't think we actually need this particular patch unless we can find an actual use case from, let's say, the last four years. Sorry for letting you do the work. Cheers, Ralf From 9e325c40fcd0d768eb3f30ba906406202f4870d7 Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sat, 19 Jun 2010 09:01:45 +0200 Subject: [PATCH] Improve and extend tests on de-ansification support. * tests/ansi.test: Make less sensitive to automake internal details. Run also make distcheck. * tests/ansi9.test: Add a trailing `:' command. * tests/ansi2.test: Likewise. Also, relax grepping of generated Makefile.in slighty w.r.t. white spaces, and improve and extend slightly comments. * tests/ansi2a.test: New test, semantic counterpart of test ansi2.test. * tests/ansi2b.test: Likewise (and sister test of ansi2a.test). * tests/ansi3.test: Rename to ... * tests/ansi3a.test: ... this, for consistency. Remove grepping of Automake's stderr w.r.t. notices about the installation of ansi2knr.c and ansi2knr.1. Do not exported CC=gcc to configure, that's already done in ./defs since we have gcc in $required. Remove some obsoleted comments. Check that source files are truly de-ansificated. Run make check and make distcheck. Test that distclean works as expected. Also try a run without forcing de-ansification. Add a trailing `:' command. Improve and extend heading comments. * tests/ansi3b.test: Likewise. * tests/ansi3c.test, ansi3d.test: New sister tests, related to ansi3a.test and ansi3b.test. * tests/ansi4.test: Do not create useless dummy source file `hello.c'. Add a trailing `:' command. * tests/ansi5.test: Move the call to `set -e' earlier (just after the inclusion of ./defs). Use the `configure.in' stub created by ./defs rather than writing it from scratch, and avoid obsoleted constructs. Do not export CC=gcc to configure, that is already done in ./defs (since we have gcc in $required). Use a much lesser hackish way to force de-ansification. Add more checks (in Makefile.am). Also run make distcheck. Add a trailing `:' command. * tests/ansi10.test: Move more checks in Makefile.am. Run also make distcheck. Output slighty improved w.r.t. debugging information. Add a trailing `:' command. Improve comments w.r.t. related tests. Other minor related and unrelated changes. * tests/ansi6.test: Likewise. Also, move the call to `set -e' earlier (just after the inclusion of ./defs), and ... (configure.in): .. use the stub created by ./defs rather than writing it from scratch, and avoid to use obsoleted forms of macros. * tests/ansi7.test: Likewise. * tests/ansi8.test: Make grepping of Automake's stderr stricter. Add a trailing `:' command. Add comment telling that this test should be kept in sync with... * tests/ansi11.test: ... this new test, sister of ansi8.test. * tests/ansi12.test: New test, for more coverage. Currently xfailing. In this test, it is not clear which part makes it xfail. * tests/ansi1.test: New test, from removed parts of ansi3.test. No new tests with oldish test names, please. Think of serial numbers that do not decrease. Check that automake can install ansi2knr.c and ansi2knr.1, and that it informs about this action. * tests/Makefile.am (TESTS, XFAIL_TESTS): Updated. --- a/tests/ansi.test +++ b/tests/ansi.test -$AUTOCONF ./configure -$MAKE test1 -$MAKE test2 + +$MAKE check +$MAKE distcheck A distcheck is not necessary here, brings no extra value AFAICS, so costs only time. I'm not just being grumpy here, testsuite slowness is a real problem, with running time of roughly two days on the MSYS system I have available to test ATM, we should not be wasting another day just because we were lazy to check whether a distcheck brings in any additional value. --- a/tests/ansi10.test +++ b/tests/ansi10.test @@ -15,8 +15,9 @@ # along with this program. If not, see http://www.gnu.org/licenses/. # Make sure ansi2knr works with $(LIBOBJS). +# See also related tests `ansi6.test' and `ansi7.test'. -required=gcc +required=gcc # FIXME: any C compiler should be ok! . ./defs || Exit 1 set -e @@ -28,11 +29,24 @@ AM_C_PROTOTYPES AC_PROG_RANLIB AC_LIBOBJ([hello]) AC_CONFIG_FILES([dir/Makefile]) +# Makefiles need to know wheter we are de-ansifing. whether ansifying, if you must use the term. For what it's worth, vim has a good and extensible spell
Re: [PATCH] Enable `set -e' in more tests (plus some tweakings).
* Stefano Lattarini wrote on Thu, Nov 11, 2010 at 03:52:39PM CET: Pinging this patch again, following this: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg3.html Patch is OK. I didn't check whether any of the tests contained constructs problematic for set -e. I'll wait the customary 72 hours (until sunday evening) before pushing. Thanks, Ralf
testsuite results from master
Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. I might be responsible for some of the failures too, but I think it's fair to guess that your patches are responsible for at least some of these. ;-) Thanks, Ralf
Re: testsuite results from master
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-201011141903417895000.txt Minimal system info: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... hikaru configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z checking build system type... sparc-sun-solaris2.10 -*-*-*- All the testsuite failures seem spurious, and due to the following rm error (in the distclean target, if I'm not mistaken): rm: Unable to remove directory ...: File exists What's going on here? Maybe NFS issues (wild guess)? http://www.unix.com/unix-dummies-questions-answers/72080-rm-unable-remove-directory-mnt-users-test-logs-file-exists.html Or something relate to FS logging or FS corruption (wilder guess)? http://www.webservertalk.com/archive101-2004-1-65261.html -*-*-*- I can say I test automake on a Solaris 10 system quite often, and the testsuite is behaving quite well there (apart from some pre-existing, mostly spurious failures). Regards, Stefano
Testsuite failures on AIX 5.3 (was: testsuite results from master)
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-20101114190221478.txt Minimal system information: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... yawara configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z running CONFIG_SHELL=/bin/sh /bin/sh ../automake/configure -C --prefix=/tmp/local/powerpc-ibm-aix5.3.0.0 checking build system type... powerpc-ibm-aix5.3.0.0 -*-*-*- FAIL: ansi.test (exit: 2) = /tmp/am/build-powerpc-ibm-aix5.3.0.0/tests:/tmp/local/powerpc-ibm-aix5.3.0.0/bin:/tmp/bin :/usr/vac/bin:/usr/vacpp/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/etc:/usr/etc + pwd /tmp/am/build-powerpc-ibm-aix5.3.0.0/tests/ansi.dir + set -e + cat + 1 Makefile.am 0 /tmp/sh663580.2 + cat + 1 configure.in 0 /tmp/sh663580.4 + : + 1 ansi2knr.c + : + 1 ansi2knr.1 + aclocal-1.11a -Werror + automake-1.11a --foreign -Werror -Wall + /bin/grep -F -v @SET_MAKE@ Makefile.in + 1 Makefile.sed + make -f Makefile.sed SHELL=/bin/sh test1 echo ' @top_srcdir@/configure.in @top_srcdir@/aclocal.m4 @srcdir@/Makefile.am \ @srcdir@/Makefile.in @top_srcdir@/configure ansi2knr.1 ansi2knr.c \ depcomp install-sh missing' | grep ' ansi2knr\.c ' @SHELL@: not found make: 1254-004 The error code from the last command is 1. Stop. + exit_status=2 IMHO this is a spurious failure due to the old hackish check: $FGREP -v @SET_MAKE@ Makefile.in Makefile.sed $MAKE -f Makefile.sed SHELL=$SHELL test1 retained from older versions of ansi.test; since this check is superseded by the later ones: $AUTOCONF ./configure $MAKE test1 my suggested fix is to just drop the hackish check. -*-*-*- FAIL: colon5.test (exit: 2) FAIL: colon6.test (exit: 2) These tests fail for the same resons of ansi.test; I suggest to drop the older hackish checks and do more proper checks with autoconf, ./configure and make. BTW, there is a pending patch of mine aimed at making the `colon*.test' tests more semantic; see: http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00110.html -*-*-*- FAIL: fn99.test (exit: 2) FAIL: fn99subdir.test (exit: 2) I'm pretty sure these tests haven't been affected by my (or yours) latest patches: the failure is pre-existent IMO. Also, the tests fails due to a segmentation fault in the (make-spawned) shell, so the failures are better investigated by someone having direct access to the system in question. -*-*-*- Regards, Stefano
Testsuite failures on Solaris 2.10 on SPARC (was: testsuite results from master)
[Reposting with a better subject. Sorry for the noise.] On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-201011141903417895000.txt Minimal system info: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... hikaru configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z checking build system type... sparc-sun-solaris2.10 -*-*-*- All the testsuite failures seem spurious, and due to the following rm error (in the distclean target, if I'm not mistaken): rm: Unable to remove directory ...: File exists What's going on here? Maybe NFS issues (wild guess)? http://www.unix.com/unix-dummies-questions-answers/72080-rm-unable-remove-directory-mnt-users-test-logs-file-exists.html Or something relate to FS logging or FS corruption (wilder guess)? http://www.webservertalk.com/archive101-2004-1-65261.html -*-*-*- I can say I test automake on a Solaris 10 system (i86pc) quite often, and the testsuite is behaving quite well there (apart from some pre-existing, mostly spurious failures). Regards, Stefano
Re: testsuite results from master
Please disregard; answer to the message Testsuite failures on Solaris 2.10 on SPARC instead. Sorry for the noise, Stefano
Re: testsuite results from master
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. Do you mean go and fix the newly introduced regressions before doing other testsuite work, or reconsider the advisability of doing testsuite work in master and/or to have a 72-hours gracetime? If you mean the former, then I agree. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, There's just two of those, so it's not a problem. and look at the lots of new failures Which of those failures are really new? Some of them involve test scripts and automake features unmodified by quite a long time. that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. That's useful. Thanks. I might be responsible for some of the failures too, but I think it's fair to guess that your patches are responsible for at least some of these. ;-) See my other answers to this thread for more information and questions. Regards, Stefano
Testsuite failures on HP-UX 11.23 (was: Re: testsuite results from master)
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-201011141903352512000.txt Minimal system information: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... ichigo configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z CONFIG_SHELL=/bin/sh /bin/sh ../automake/configure checking build system type... hppa2.0w-hp-hpux11.23 -*-*-*- FAIL: instspc-space-build.test (exit: 1) FAIL: instspc-space-install.test (exit: 1) FAIL: instspc-tab-build.test (exit: 1) FAIL: instspc-tab-install.test (exit: 1) Hmpf. Not very nice. Apparently, the whitespaces got eaten somehow in the make rules: ../install-sh -c -d '/tmp/am/build-hppa2.0w-hp-hpux11.23/tests/instspc-space-build.dir/sub1/ -prefix/foo/sub' OK, space is there ... ../install-sh -c -m 644 ../sub/nobase.h '/tmp/am/build-hppa2.0w-hp-hpux11.23/tests/instspc-space-build.dir/sub1/ -prefix/foo/sub' ... and here ... test -f '/tmp/am/build-hppa2.0w-hp-hpux11.23/tests/instspc-space-build.dir/sub1/-prefix/foo/sub/nobase.h' ... but not here! *** Error exit code 1 And failure ensues. My knee-jerk guess is that the (leading?) whitespaces got stripped from the variable `file' even if it's defined from the command line: DESTDIR=$dest file=$instspc_test_string $MAKE -e test-install-sep Is this guess correct? Is this a known limitation/bug of HP-UX make? Is it worth working around? (e.g. by adding some more sanity checks and skipping the test if they fail) FAIL: instspc-formfeed-build.test (exit: 1) FAIL: instspc-formfeed-install.test (exit: 1) FAIL: instspc-carriageret-build.test (exit: 1) FAIL: instspc-carriageret-install.test (exit: 1) On the other hand, I wouldn't care about these failures. Getting to the point: how was the older `instspc.test' behaving on this system? Without knowing that, it's hard to tell if we've introduced a regression, or are just hitting known bugs/limits of HP-UX. -*-*-*- FAIL: parallel-tests.test (exit: 1) Not caused by recent testsuite work (and I can't easily guess why it's failing). FAIL: spy.test (exit: 1) This is not really a test on automake/aclocal, but a spy test on the make implementation available, to see if double-colon rules work for it. The heading comments read: # Check whether double colon rules work. The Unix V7 make manual # mentions double-colon rules, but POSIX does not. They seem to be # supported by all Make implementation as we can tell. This test case # is a spy: we want to detect if there exist implementations where # these do not work. We might use these rules to simplify the rebuild # rules (instead of the $? hack). But currently automake doesn't use double-colon rules in the generated makefiles, so no big deal IMHO. -*-*-*- FAIL: distlinksbrk.test (exit: 1) = /tmp/am/build-hppa2.0w-hp-hpux11.23/tests:/tmp/local/hppa2.0w-hp-hpux11.23/bin :/tmp/bin:/opt/aCC/bin:/opt/ansic/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11 :/usr/ccs/bin:/usr/contrib/bin/X11:/usr/vue/bin:/opt/imake/bin + pwd /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir + set -e + lnk_base=BrknSymlnk + lnk1=BrknSymlnk__001 + lnk2=BrknSymlnk__002 + lnka=BrknSymlnk__aaa + lnkb=BrknSymlnk__bbb + ln -s nonesuch BrknSymlnk__001 + pwd + ln -s /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir/nonesuch BrknSymlnk__002 + ln -s BrknSymlnk__001 BrknSymlnk__aaa + ln -s BrknSymlnk__aaa BrknSymlnk__bbb + test ! -r BrknSymlnk__001 + test ! -r BrknSymlnk__002 + test ! -r BrknSymlnk__aaa + test ! -r BrknSymlnk__bbb + test -h BrknSymlnk__001 + test -h BrknSymlnk__002 + test -h BrknSymlnk__aaa + test -h BrknSymlnk__bbb + cat + 1 configure.in 0 /var/tmp/sh13163.8 + cat + 1 Makefile.am 0 EXTRA_DIST = BrknSymlnk__001 BrknSymlnk__002 BrknSymlnk__aaa BrknSymlnk__bbb + ls -l total 18 lrwxrwxr-x 1 rwild rwild8 Nov 12 20:16 BrknSymlnk__001 - nonesuch lrwxrwxr-x 1 rwild rwild 74 Nov 12 20:16 BrknSymlnk__002 - /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir/nonesuch lrwxrwxr-x 1 rwild rwild 15 Nov 12 20:16 BrknSymlnk__aaa - BrknSymlnk__001 lrwxrwxr-x 1 rwild rwild 15 Nov 12 20:16 BrknSymlnk__bbb - BrknSymlnk__aaa -rw-rw-r-- 1 rwild rwild 77 Nov 12 20:16 Makefile.am -rw-rw-r-- 1 rwild rwild 86 Nov 12 20:16 configure.in -rwxr-xr-x 1 rwild rwild20001 Nov 12 20:16 depcomp -rwxr-xr-x 1
Testsuite results on FreeBSD 6.4 on i386 (was: testsuite results from master)
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-201011141903469617000.txt Minimal system information: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... thor configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/bash ../automake/configure checking build system type... i386-unknown-freebsd6.4 -*-*-*- Well, it seems the testsuite is passing here... No FAIL'd test that I can see! Am I missing something? Regards, Stefano
Re: Testsuite failures on Tru64 OSF 5.1
On Monday 15 November 2010, Peter Rosin wrote: Running MSVC on osfX.Y is not interesting. I'd write a patch to skip the test Yeah, I agree this is the best option. but I can't then test the result. Me neither (I don't have access to a True64/OSF system). So I won't... Neither will I ;-) Thanks for the quick feedback, Stefano
Testsuite failures on IRIX 6.5 (was: testsuite results from master)
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-20101114190370844.txt Minimal system information: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... puar configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z running CONFIG_SHELL=/bin/sh /bin/sh ../automake/configure PERL=/opt/fsw/perl586/bin/perl checking build system type... mips-sgi-irix6.5 -*-*-*- I see many failures similar to this one (taken from backcompat6.log): config.status: executing depfiles commands make all-am source='quux.c' object='quux.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../depcomp \ cc -DHAVE_CONFIG_H -I. -I.. -g -c quux.c cc ERROR: file does not exist: quux.c It should be `../quux.c' here, since it is a VPATH build. Is this a bug in automake or in VPATH support of IRIX make? Should the makefile fragment: source='$' object='$@' libtool=no \ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \ $(COMPILE) -c $ be rewritten as follows? source='$' object='$@' libtool=no \ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \ $(COMPILE) -c `test -f $ || echo $(srcdir)`/$ -*-*-*- FAIL: instspc-*-build.test FAIL: instspc-*-install.test Sample: + make source='source.c' object='source.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../depcomp \ cc -DPACKAGE_NAME=\instspc-bang-build\ -DPACKAGE_TARNAME=\instspc-bang-build\ \ -DPACKAGE_VERSION=\1.0\ -DPACKAGE_STRING=\instspc-bang-build\ 1.0\ \ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\instspc-bang-build\ \ -DVERSION=\1.0\ -I. -I.. -g -c source.c cc ERROR: file does not exist: source.c *** Error code 2 (bu21) So this failures are not due to the recent instspc*.test refactoring, but to the same VPATH issue described above. -*-*-*- FAIL: distlinksbrk.test (exit: 1) = /tmp/am/build-mips-sgi-irix6.5/tests:/tmp/local/mips-sgi-irix6.5/bi n:/tmp/bin:/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/etc:/usr/bin/X11 :/usr/bsd + pwd /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir + set -e + lnk_base=BrknSymlnk + lnk1=BrknSymlnk__001 + lnk2=BrknSymlnk__002 + lnka=BrknSymlnk__aaa + lnkb=BrknSymlnk__bbb + ln -s nonesuch BrknSymlnk__001 + pwd + ln -s /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir/nonesuch BrknSymlnk__002 + ln -s BrknSymlnk__001 BrknSymlnk__aaa + ln -s BrknSymlnk__aaa BrknSymlnk__bbb + test ! -r BrknSymlnk__001 + test ! -r BrknSymlnk__002 + test ! -r BrknSymlnk__aaa + test ! -r BrknSymlnk__bbb + test -h BrknSymlnk__001 + test -h BrknSymlnk__002 + test -h BrknSymlnk__aaa + test -h BrknSymlnk__bbb + cat + 1 configure.in 0 /tmp/sh791237.2 + cat + 1 Makefile.am 0 EXTRA_DIST = BrknSymlnk__001 BrknSymlnk__002 BrknSymlnk__aaa BrknSymlnk__bbb + ls -l total 92 lrwxrwxr-x1 rwildrwild 8 Nov 12 20:31 BrknSymlnk__001 - nonesuch lrwxrwxr-x1 rwildrwild 69 Nov 12 20:31 BrknSymlnk__002 - /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir/nonesuch lrwxrwxr-x1 rwildrwild 15 Nov 12 20:31 BrknSymlnk__aaa - BrknSymlnk__001 lrwxrwxr-x1 rwildrwild 15 Nov 12 20:31 BrknSymlnk__bbb - BrknSymlnk__aaa -rw-rw-r--1 rwildrwild 77 Nov 12 20:31 Makefile.am -rw-rw-r--1 rwildrwild 86 Nov 12 20:31 configure.in -rwxr-xr-x1 rwildrwild 20001 Nov 12 20:31 depcomp -rwxr-xr-x1 rwildrwild 13781 Nov 12 20:31 install-sh -rwxr-xr-x1 rwildrwild 11419 Nov 12 20:31 missing + aclocal-1.11a -Werror + autoconf + automake-1.11a --foreign -Werror -Wall + ./configure checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile + make distdir UX:make: ERROR: don't know how to make BrknSymlnk__001 (bu42). + make -k distdir + 1 out 2 1 + : + cat out UX:make: ERROR: don't know how to make BrknSymlnk__001 (bu42). Just an error message instead of four? Might this be a make -k bug? If yes, how does the attached test script fare? + /bin/grep -F BrknSymlnk__001 out UX:make: ERROR: don't know how to
[PATCH] tests/yaccdry.test ($required): Require bison. (was: Re: More problems with `make -n' in automake-generated rules.)
I'm seeing this failure in test yaccdry.test at the Hydra continuous build system for automake: http://hydra.nixos.org/build/745050/log FAIL: yaccdry.test (exit: 2) /tmp/nix-build-9l5zbyj69kwsr3iyps70a2a5nsnpj7hn-automake-1.11a.drv-0/automake-1.11a/tests:/... ++ pwd /tmp/nix-build-9l5zbyj69kwsr3iyps70a2a5nsnpj7hn-automake-1.11a.drv-0/automake-1.11a/tests/yaccdry.dir + set -e + cat + cat + cat + cat + aclocal-1.11a -Werror + automake-1.11a --foreign -Werror -Wall --add-missing configure.in: installing `./ylwrap' + autoconf + ./configure checking for a BSD-compatible install... /...-coreutils-8.4/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /...-coreutils-8.4/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for bison... no checking for byacc... no configure: creating ./config.status config.status: creating Makefile config.status: executing depfiles commands + make gcc -DPACKAGE_NAME=\yaccdry\ -DPACKAGE_TARNAME=\yaccdry\ \ -DPACKAGE_VERSION=\1.0\ -DPACKAGE_STRING=\yaccdry\ 1.0\ \ -DPACKAGE_BUGREPORT=\\ - DPACKAGE_URL=\\ \ -DPACKAGE=\yaccdry\ -DVERSION=\1.0\ \ -I. -g -O2 \ -MT foo.o -MD -MP -MF .deps/foo.Tpo -c -o foo.o foo.c mv -f .deps/foo.Tpo .deps/foo.Po /bin/sh ./ylwrap parse.y y.tab.c parse.c y.tab.h parse.h y.output parse.output -- yacc -d ./ylwrap: line 113: yacc: command not found make: *** [parse.c] Error 1 + exit_status=2 + set +e + cd /tmp/nix-build-9l5zbyj69kwsr3iyps70a2a5nsnpj7hn-automake-1.11a.drv-0/automake-1.11a/tests + case $exit_status,$keep_testdirs in + test 0 '!=' 0 + echo 'yaccdry: exit 2' yaccdry: exit 2 + exit 2 OK to apply the attached patch to a temporary bugfix branch to be then merged into maint? Regards, Stefano From 279d77d1043a0d5235b88ddba99d05fdc2be96ee Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Mon, 15 Nov 2010 02:12:10 +0100 Subject: [PATCH] tests/yaccdry.test ($required): Require bison. --- ChangeLog |4 tests/yaccdry.test |1 + 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6c17cd3..af7e7cd 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2010-11-15 Stefano Lattarini stefano.lattar...@gmail.com + + * tests/yaccdry.test ($required): Require bison. + 2010-11-01 Ralf Wildenhues ralf.wildenh...@gmx.de Fix and document rules to not touch the tree with `make -n'. diff --git a/tests/yaccdry.test b/tests/yaccdry.test index d11d3fe..d2e7632 100755 --- a/tests/yaccdry.test +++ b/tests/yaccdry.test @@ -16,6 +16,7 @@ # Removal recovery rules for headers should not remove files with `make -n'. +required=bison . ./defs || Exit 1 set -e -- 1.7.1
Re: [PATCH] {maint} Improve and extend tests on de-ansification support.
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hi Stefano, * Stefano Lattarini wrote on Mon, Sep 13, 2010 at 10:59:22AM CEST: But since we are at it, we can do better, extending coverage and making existing tests more semantic. See the attached patch (for maint). ansi2knr is a really dying (and ugly) feature; when have we last seen a compiler that does not support C89? Honestly, I never did :-) I'm not sure if it's time to deprecate it yet, I'd like to deprecate it (if it's not worth testing better, it's not worth keeping IMHO). But I'll follow your lead here. but it is definitely not worth putting a lot of effort into. That said, I did a review of this patch; please read it and apply it to other testsuite patches. I agree with most of your observations, but I have a couple of nits below. I don't think we actually need this particular patch unless we can find an actual use case from, let's say, the last four years. Let's hope not. I'd like this feature to die ASAP. Sorry for letting you do the work. I could have asked before. --- a/tests/ansi.test +++ b/tests/ansi.test -$AUTOCONF ./configure -$MAKE test1 -$MAKE test2 + +$MAKE check +$MAKE distcheck A distcheck is not necessary here, brings no extra value AFAICS, so costs only time. I'm not just being grumpy here, testsuite slowness is a real problem, with running time of roughly two days on the MSYS system I have available to test ATM, we should not be wasting another day just because we were lazy to check whether a distcheck brings in any additional value. Some time ago (in a thread whose subject and topic I've forgotten) you told me you tend to add a make distcheck at the end of test cases if that's at all possible, to ensure the test data is self-contained, and that the tested features don't break in obvious ways when doing a VPATH build. Back then I agreed to you that it was a good idea, and I still do. And I don't think that slowness on some systems should prevent us from writing better tests, especially when doing so is almost effortless in terms of programmer time and commitment. dream This problem and similar ones would probably be mitigated by having some more CI servers testing automake automatically... Just think how useful the Hydra build server has been in finding (also elusive) bugs! /dream + +cat Makefile.am 'END' +AUTOMAKE_OPTIONS = ansi2knr no-dependencies +bin_PROGRAMS = hello + +.PHONY: debug-info +debug-info: + ls -l $(srcdir) + test x'$(srcdir)' = x'.' || ls -l $(builddir) + @echo ' --- $@ ---' + @echo ' ac_cv_prog_cc_stdc=$(ac_cv_prog_cc_stdc)' + @echo ' ANSI2KNR=$(ANSI2KNR)' + @echo ' U=$(U)' + @echo '---' Please, stick to GNU Coding Standards style output. You keep making up new kinds of this output must stick out more from the rest stuff, and in different ways each time, that looks incoherent when seen as a whole. Let's please move away from that in any new patches. Thanks. You are so right here. Sorry. tail might not grok -n. (/usr/bin/tail on Solaris) Hmpf. Why do these at configure time/at make time have to be in separate tests? To keep tests more granular, esp. in case of failure. Not a big deal though. The setup overhead seems to dominate. I deemed this overhead to be acceptable. +# Try to force de-ansification at configure time. +./configure ac_cv_prog_cc_stdc=no +$MAKE check +$MAKE distcheck DISTCHECK_CONFIGURE_FLAGS='ac_cv_prog_cc_stdc=no' maintainer-check clean? But the above should (and currently do) work also with make implementations that don't propagate command-line variables to submake calls. I don't agree that we should relax the tests just to please maintainer-check. Regards, Stefano
Re: testsuite results from master
* Stefano Lattarini wrote on Mon, Nov 15, 2010 at 12:19:00AM CET: On Sunday 14 November 2010, Ralf Wildenhues wrote: I think it is time to reevaluate some of the work that has been done in the last few weeks. Do you mean go and fix the newly introduced regressions before doing other testsuite work, or reconsider the advisability of doing testsuite work in master and/or to have a 72-hours gracetime? If you mean the former, then I agree. Yes, I mean the former. and look at the lots of new failures Which of those failures are really new? Some of them involve test scripts and automake features unmodified by quite a long time. I might be responsible for some of the failures too, but I think it's fair to guess that your patches are responsible for at least some of these. ;-) See my other answers to this thread for more information and questions. I will try to address your questions when I have time (i.e., tonight at the earliest), but it would really help if you had access yourself. Thanks, Ralf
Re: User extensions
Hello Pippijn. On Saturday 13 November 2010, Pippijn van wrote: On Mon, Nov 01, 2010 at 08:18:44PM +0100, Ralf Wildenhues wrote: Ideally, I would like to see testsuite coverage for each code path (branch coverage) for new code. I understand that only Stefano is able to produce this in reasonable amount of time, so whatever you guys can manage is better than nothing. Hi, not having followed the code discussion very closely (just hoping it will be in git, soon, so I can start using it, as I have been waiting for something like this for a long time), I just wonder what you mean by branch coverage. If this is execution graph node coverage, then I agree, but if you mean edge coverage, I don't know how you want to achieve this. Any O(x) where x1 algorithm anywhere in the code makes it impossible. If I'm wrong, I'd like to know how Stefano produces it. Well, basically by hand. I think that Ralf was just saying that, since I'm familiar with the automake testsuite and interested in extending it, since I presently have definitely more time to do so than Ralf has, and, above all, since there's no other regular contributor to automake ATM, if someone is able to add proper testing for the new feature, that's either me or the original contributor of the feature (Valentin David). But it's not like I have a silver bullet to write proper tests which attain complete branch coverage; I just proceed by common sense, trying to maximize such coverage. That's all, sadly. Regards, Stefano
Re: User extensions
* Stefano Lattarini wrote on Sun, Nov 14, 2010 at 01:36:16PM CET: But it's not like I have a silver bullet to write proper tests which attain complete branch coverage; I just proceed by common sense, trying to maximize such coverage. That's all, sadly. A while ago I posted instructions on how to generate coverage information for the perl parts of Automake, including results: http://thread.gmane.org/gmane.comp.sysutils.automake.general/11088 That doesn't help for shell or makefile snippets, but it's a whole lot better than nothing. Cheers, Ralf
Re: builddir
Hello Russell, * Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET: In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only. Automake 1.9.6 is very old. Presumably you're using an ancient version of Autoconf too, please state which. Normally I'd say upgrade and retry, but I might look at this if you post a small reproducer. Thanks, Ralf
Re: User extensions
On Sunday 14 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sun, Nov 14, 2010 at 01:36:16PM CET: But it's not like I have a silver bullet to write proper tests which attain complete branch coverage; I just proceed by common sense, trying to maximize such coverage. That's all, sadly. A while ago I posted instructions on how to generate coverage information for the perl parts of Automake, including results: http://thread.gmane.org/gmane.comp.sysutils.automake.general/11088 Interesting. Somehow I missed (or I forgot) that. Thanks for the reminder. That doesn't help for shell or makefile snippets, but it's a whole lot better than nothing. Cheers, Ralf Regards, Stefano
Re: builddir
On 15/11/10 01:10, Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET: In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only. Automake 1.9.6 is very old. Presumably you're using an ancient version of Autoconf too, please state which. Normally I'd say upgrade and retry, but I might look at this if you post a small reproducer. Hi, I had a closer look at my system and found the debian alternatives system was pointing at an old version. I set it right now thanks.
Re: ACLOCAL best practice
Hello Ryan, * Ryan Lortie wrote on Sat, Nov 13, 2010 at 05:49:57PM CET: I recently filed a bug against a freedesktop.org component because it didn't honour the ACLOCAL_FLAGS environment variable. That bug got closed, telling me to use ACLOCAL like so: ACLOCAL='aclocal -I /home/desrt/local/share/aclocal To add to Stefano's reply, the above also has the disadvantage that the first -I argument is special to aclocal --install, see info Automake 'aclocal Options' Cheers, Ralf
Re: [Vala] automake 1.11.1: unable to build vala project out-of-tree
Hello, في ح، 07-11-2010 عند 09:12 +0300 ، كتب Andrey Borzenkov: Automake assumes the .c files generated by vala are distributed with the source, and this isn't true when building from git. A solution is to do an in-tree build, make distclean, and re-run your out-of-tree build. The problem is you have to do this dance every time a vala file changes, so in practice, out-of-tree build isn't supported for development, only for release tarballs. I am afraid it does not answer my question. Yes, .c generated from .vala are disributed, but why automake deliberately emits code that cannot built .c files from .vala in *source* directory? Because you requested an out-of-tree build, I guess. The vala build is different enough that some assumptions in automake don't hold. The following crude change to final Makefile builds files in (srcdir) when started from build directory: [...] Do you see any immediate problem with this change? Could automake generate similar code by default? While this seems a bit weird (to touch the source dir for an out-of-tree build), if automake devs are ok I think it won't hurt :-) wishlist A possible solution is to have automake (optionally) not distribute the generated .c files (so they end up in the build dir rather than the source dir) and that could be used in development if out-of-tree builds are needed. /wishlist While this is nice wishlist, it is rather orthogonal to discussed problem :) As I see it, if automake can generate a makefile that compiles the vala code in the build dir, it would solve your build failure as well :-) Regards, Abderrahim P.S. I don't know automake that well, I'm just a vala fanboy trying to help :-)
