Re: When aclocal causes an error message, sed: invalid option -- 'q'
* Bruce Korb wrote on Tue, Nov 16, 2010 at 10:18:50PM CET: On 11/16/10 12:45, Ralf Wildenhues wrote: This comes probably from autoreconf, not from aclocal. That is rather difficult to discern. Either way, the controlling program needs to say: I was running this script:\n%s\nAND:\n%s which might get wrapped again by autoreconf (or not). Hmm. This is GNU/Linux -- openSuSE 11.3 I think it is seeing -q on the command line. OK. I don't see where it should come from in Autoconf nor Automake. Any case the package at hand contains m4_esyscmd in configure.ac that contains a buggy sed script? If not, please state exact versions of autotools programs used, and show autoreconf -v output. Thanks, Ralf
Re: Testsuite failures on AIX 5.3
* Stefano Lattarini wrote on Sun, Nov 14, 2010 at 10:14:54PM CET: http://autobuild.josefsson.org/automake/log-20101114190221478.txt + /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. But then I'm wondering why this code did not fail in the past. Must be a regression of some kind, either in the tests, or defs.in, or in other code. 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 Changing that shouldn't be done to cover up a regression though. 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. Yes, indeed. This is fairly long-standing. 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. Thanks, Ralf
Re: Testsuite failures on Tru64 OSF 5.1
Hi Peter,
* Peter Rosin wrote on Mon, Nov 15, 2010 at 09:19:44AM CET:
This is based off of master (but I guess it also applies to tests-init)
but the backport to the msvc branch is trivial. I stole the xsi-test
from libtool.
Would be good if someone tested on that Alpha before pushing I suppose.
Patch is ok if we also have test coverage of 'compile' in non-MSVC mode
on this system (so we can be sure that the shell doesn't barf skipping
over the XSI code bits). You can omit dropping the output as you like.
Thanks for the quick feedback!
Cheers,
Ralf
Subject: [PATCH] Skip MSVC oriented tests if the shell is not capable.
* tests/defs: New required entry 'xsi-shell'.
* tests/ar-lib.test, tests/compile3.test, tests/compile6.test:
Require a XSI capable shell.
--- a/tests/defs
+++ b/tests/defs
@@ -290,6 +290,15 @@ do
echo $me: running texi2dvi -o /dev/null --version
( texi2dvi -o /dev/null --version ) || exit 77
;;
+xsi-shell)
+ # Try some XSI features.
+ echo $me: trying some XSI constructs
+ ( _am_dummy=a/b/c
+ test
${_am_dummy##*/},${_am_dummy%/*},${_am_dummy#??}${_am_dummy%$_am_dummy}, \
+ = c,a/b,b/c, \
+ eval 'test $(( 1 + 1 )) -eq 2 \
+ test ${#_am_dummy} -eq 5' ) /dev/null 21 || exit 77
+ ;;
*)
# Generic case: the tool must support --version.
echo $me: running $tool --version
Re: Testsuite failures on Tru64 OSF 5.1
* Stefano Lattarini wrote on Sun, Nov 14, 2010 at 11:00:16PM CET: http://autobuild.josefsson.org/automake/log-201011141902490189000.txt FAIL: backcompat5.test (exit: 1) [CUT] find ../foo-1.0 -print ## useful for debugging find: missing conjunction *** Exit 1 Stop. Seems like a limitation (bug) of the find utility; what I'd do is replacing the above find command simply with: find ../foo-1.0 WDYT? I think the comment is taken as part of the command. There shouldn't be any comments in recipe commands. FAIL: instspc-*-build.test (exit: 1) FAIL: instspc-*-install.test (exit: 1) Re-running the tests with `/bin/ksh -x' might really help here. No idea what might have ben gone wrong otherwise. And yes, this is clearly a bug introduced by my recent instspc.test refactoring patch. Not sure. instspc.test was skipped on most of my test systems because I did not have gcc in $PATH (deliberately, but for other reasons). How come the verbose output didn't land in test-suite.log though? Rest comes later. Cheers, Ralf
Re: build the same source twice with different macros
Hi Nicolas, * Nicolas Bock wrote on Mon, Nov 15, 2010 at 05:11:26PM CET: (1) I can use C++ and rewrite the function header as a template. (2) I can define a macro for the preprocessor that is either defined as float or double and then compile the function source twice, the first time with $CC -DFLOAT=float and the second time with $CC -DFLOAT=double. Is option (2) possible within automake without excessive hackery? Yes. Is it advisable? Is there a third option that I might want to consider? I'd say it's normal mumbo jumbo. See 'info Automake true'. bin_PROGRAMS = foo foo_SOURCES = ... (other sources) foo_LDADD = libfood.a libfoof.a noinst_LIBRARIES = libfood.a libfoof.a libfood_a_SOURCES = bar.c libfoof_a_SOURCES = $(libfood_a_SOURCES) libfood_a_CPPFLAGS = -DFLOAT=float Hope that helps. Cheers, Ralf
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: [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
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
* 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
* 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: 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
bug#7379: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
[ Thanks Glenn for rerouting the bug report! ] Hi Behdad, From: Behdad Esfahbod Subject: On the fix for CVE-2009-4029 Automake security fix for 'make dist*' Date: Thu, 11 Nov 2010 16:17:22 -0500 I recently read about the fix for the chmod 777 issue. Just wanted to note that it may be preferred if you continue with chmod 777 and instead fix the problem by moving the dist dir inside another direction that is 700. The reason a 777 mod in the tarball may be preferred (or 775 for that matter, but not 755) is for systems that users of a group are using sticky-bit on the group to share writable files with eachother. By letting the umask decide what bits should not be set you you enable such settings, whereas using 755, the user expanding the tarball has to reset it to 775 or the rest of the group cannot write to it. Thanks for the bug report. At the time we fixed this, we considered going this other option. It was a fairly close call. The downside of the solution you suggest was that it would complicate 'make dist' a little, and maybe break a few packages that rely on the exact subdir structure of $(distdir) being one directory below the toplevel build directory. Such reliance is probably bad style anyway, but we didn't know of many uses that would benefit from more relaxed permission inside the tarball. How useful is that for you, how come you don't use a version control repository rather than an extracted tarball for collaborative work (honest question)? You are the first person to report this in the 12 months since we released fixed versions of Automake. I don't have other data to go on but it thus doesn't seem to be a very wide spread issue to me, and there's the obvious workaround of a chmod -R after extraction, no? I'm open to arguments here, but so far I'm slightly leaning toward keeping the current behavior. Thanks, Ralf
Re: [PATCH] {master} Deprecate obsoleted macro AM_WITH_REGEX.
* Stefano Lattarini wrote on Sat, Nov 13, 2010 at 12:32:49PM CET:
* m4/regex.m4: Document the `AM_WITH_REGEX' macro as obsoleted,
I think technically obsolete is right here, without trailing d.
and tell that it should be removed two years from now.
s/tell/state/
(AM_WITH_REGEX): Raise an m4-time warning of the obsolete
category when this macro is used.
* doc/automake.texi (Public Macros): Move description of
`AM_WITH_REGEX' from here ...
(Private Macros): ... to here, and declare it as obsoleted and
Did you mean (Obsolete Macros) here?
to be removed in a future version.
* tests/regex-obsolete.test: New test.
That file is missing from the patch. Please resend and I'll finish the
review.
* tests/Makefile.am (TESTS): Update.
+...@item AM_WITH_REGEX
+...@acindex AM_WITH_REGEX
+...@vindex WITH_REGEX
+...@opindex --with-regex
+...@cindex regex package
+...@cindex rx package
+Adds @option{--with-regex} to the @command{configure} command line. If
+specified (the default), then the @samp{regex} regular expression
+library is used, @file{regex.o} is put into @code{LIBOBJS}, and
+...@code{with_regex} is defined. If @option{--without-regex} is given, then
+the @code{rx} regular expression library is used, and @file{rx.o} is put
+into @code{LIBOBJS}. This macro is obsolete now (since rx doesn't seem
+to be maintained), and will be removed in a future version of Automake.
Is rx a package? Where did you find traces to it?
How about adding Consider using gnulib if you need regex
functionality.?
@end table
Thanks,
Ralf
Re: [PATCH 1/3] aclocal: handle ACLOCAL_PATH environment variable
* Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:38PM CET:
This updated patch passes the tests suggested by Stefano. Considering
that Automake will rarely if ever be invoked from outside, MSYS, I stuck
with the colon as the sole separator for ACLOCAL_PATH.
The test suites leaves the user's ACLOCAL_PATH in place, for consistency
with the treatment of ${prefix}/share/aclocal/dirlist in tests/defs.in,
but overrides it in the two dedicated tests.
I needed to tweak the tests/aclocal.in script to avoid passing the
srcdir to -I (which happens if building in srcdir). Otherwise, the
assumptions of the precedence tests in acloca25.test are not respected.
* NEWS: Document new behavior.
* aclocal.in (parse_arguments): Parse ACLOCAL_PATH as a colon-separated
list of directories to be included in the search path.
* doc/automake.texi (Macro Search Path): Document new behavior and
the precedence rules for various elements of the search path.
* tests/Makefile.am (TESTS): Add new testcases.
* tests/acloca24.test: New testcase.
* tests/acloca25.test: New testcase.
* tests/aclocal.in: Special-case in-srcdir build, so that -I is not used
if it brings in unwanted m4 files.
This patch is OK. I've committed it locally to a new branch based off
maint (but the change is intended for master only of course), and can
push it for you when we've dealt with the other ones. (Ping me if you'd
like write access to automake.git, AFAICS you don't have that ATM.)
Thanks,
Ralf
Re: [PATCH] {master} Deprecate obsoleted macro AM_WITH_REGEX.
* Stefano Lattarini wrote on Sat, Nov 13, 2010 at 01:39:04PM CET: On Saturday 13 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sat, Nov 13, 2010 at 12:32:49PM CET: Is rx a package? Where did you find traces to it? There was this in automake.texi: @cindex rx package Also, older comments in m4/regex.m4 read: # FIXME: This macro seems quite obsolete now since rx doesn't seem to # be maintained, while regex is. But I agree that the warning in AM_WITH_REGEX could be simplified to: $0 is obsolete, since `rx' is unmantained now That's what I've done in the attached amended patch. Cool. Thanks for digging. Patch is OK for master. Thanks! Ralf
Re: How to structure a GNU scientific project
Hello Luke, you somehow managed to send mail to the automake list without the list address in Cc:, let's fix that. * Luke wrote on Mon, Nov 08, 2010 at 07:36:13PM CET: I'm trying to organize the directory and file structure of my project and figure out how everything should be installed in a way that complies with the GCS and FHS. Currently, my project provides several command line binary executables that do some numerical number crunching using GNU GSL. The inputs to these binaries are a few human readable text files which specify some simulation parameters and settings. The outputs of the executables are a couple of data files (time histories, level curves, etc.) and a couple of text files that show the simulation settings that were actually used and specify the format of the output data. On top of this, I have some Python scripts which generate plots from the data files, and save them as pdfs. The python scripts call os.system to specify the simulation inputs, run the simulation, and process output data to make some plots. It also takes all inputs and outputs (input text files + output data + plots) and bundles them into a time-stamped tar.gz file so that multiple simulation runs don't overwrite each other, and to provide a way to go back and look at simulation results and know exactly what conditions created them. I have several sets of example input text files that allow a user to run the simulations with some default parameters. I'm not clear on where these files should be placed in the source distribution and where they should be installed during 'make install'. I would like a user to be able to easily find and open these text files so they can use them as templates for running simulations with different parameters. My questions are: 1) Where should I put these text simulation configuration files within my source distribution, Whereever they suit you best. There is no standard requirement for this. It is often helpful to have at least a similar directory structure in the source tree than in the install tree (e.g., for the subtree of all configuration files and directories). and where should they be installed to by default? We put them below $(pkgdatadir), if they are system-independent: examplesdir = $(pkgdatadir)/examples examples_DATA = ... Read-only configuration files for programs pertaining to a single system can go in sysconfdir ($(prefix)/etc by default), but that is not typically useful for simulation configuration files. 2) How should I make my application and/or user aware of where they are installed? The way these files are used is by specifying a command line flag that directs the executable to parse a particular input file, so in order for this to be useful, the directory they are installed into must be known. See 'info Autoconf Defining Directories' for how to pass configure information to your code. It is very useful to be able to override the location with a command-line option, so that you can test programs in your test suite before they are installed. 3) Should the python scripts go in site-packages, or would it make more sense for them to be installed alongside the binary executables? Are they programs that are independently useful on their own, i.e., may be called by the user, or just invoked from within your code? If the former, I'd make them bin_SCRIPTS (so ending up in $(bindir)), otherwise I guess it might depend. Auxiliary programs usually go in libexecdir, python modules in the python tree. The python documentation might have more suggestions here. 4) I use the python scripts to save everything in a results/ folder (and I'm often working with my source directory, so this is src/results). It seems like this folder ought to be in the users home directory somewhere, but maybe there are other places it would make sense to put this type of output data? Output should IMVHO generally be relative to the current working directory, and be configurable by either a command-line option, and/or a setting in the configuration files. The user should be able to run multiple instances of your programs concurrently without having to worry about them overwriting each others results. In case you worry about MPI, nowadays I don't know of any startup mechanisms any more that don't allow you to specify the working directory of the running code. It seems like the text input files should go in a subdirectory of /usr/local/share, or maybe the whole project should go into a subdirectory of /opt. Leave that to the user to decide. Without configure switches, prefix will default to /usr/local, thus datarootdir to /usr/local/share, thus datadir to /usr/local/share, thus pkgdatadir to /usr/local/share/$PACKAGE. Each level can be overridden, so './configure --prefix=/opt' will install everything below /opt. The unprivileged user should be able to install below her $HOME with './configure --prefix=$HOME/local' or so.
Re: [PATCH] New tests on obsoleted usages of automake/autoconf macros.
Hi Stefano,
* Stefano Lattarini wrote on Wed, Nov 03, 2010 at 07:12:27PM CET:
http://lists.gnu.org/archive/html/automake-patches/2010-11/msg3.html
[...]
--- /dev/null
+++ b/tests/backcompat6.test
@@ -0,0 +1,105 @@
+# Backward-compatibility test: try to build and distribute a package
+# using obsoleted forms of AC_INIT, AM_INIT_AUTOMAKE and AC_OUTPUT.
+# This script can also serve as mild stress-testing for Automke.
+# See also the similar test `backcompat5.test'.
+cat Makefile.am 'END'
+bin_PROGRAMS = foo
+foo_SOURCES = quux.c
+DISTCLEANFILES = *.tmp
+check-local:
+ rm -f exp got
+ echo 'PACKAGE = nonesuch-zardoz' exp.tmp
+ echo 'VERSION = nonesuch-0.1' exp.tmp
+ echo 'PACKAGE = $(PACKAGE)' got1.tmp
+ echo 'VERSION = $(VERSION)' got1.tmp
+ ./foo got2.tmp
+ cat exp.tmp
+ cat got1.tmp
+ cat got2.tmp
+ diff exp.tmp got1.tmp
+ diff exp.tmp got2.tmp
+END
+
+cat quux.c 'END'
+#include config.h
+#include stdio.h
+int main (void)
+{
+ printf(PACKAGE = %s\nVERSION = %s\n, PACKAGE, VERSION);
+ return 0;
+}
+END
The diff between exp.tmp and got2.tmp fails on MinGW/MSYS because the
foo program uses w32-style CRLF newlines whereas the shell prints LF
only.
The easiest fix would be to grep for the lines in question, I guess.
Thanks,
Ralf
Re: [PATCH] {maint} More tests on macro `AM_WITH_REGEX'.
Hello Stefano, * Stefano Lattarini wrote on Mon, Sep 20, 2010 at 11:08:34PM CEST: This patch increase coverage for a macro I'm planning to touch soon (to make it use AS_HELP_STRING). OK for maint? Does *anybody* use AM_WITH_REGEX? Have you checked? This seems so obsoleted by gnulib that I don't think it is worth investing any more time into. More tests on macro `AM_WITH_REGEX'. * tests/regex.test: Extend with more configure runs. Add trailing `:' command. * tests/regex2.test: New test. * tests/regex3.test: Likewise. * tests/Makefile.am (TESTS): Updated --- a/tests/regex.test +++ b/tests/regex.test @@ -15,6 +15,7 @@ # along with this program. If not, see http://www.gnu.org/licenses/. # Make sure AM_WITH_REGEX compiles and runs. +# See also related tests `regex2.test' and `regex3.test' . ./defs || Exit 1 @@ -28,3 +29,8 @@ $ACLOCAL $AUTOCONF ./configure ./configure --without-regex +./configure --with-regex +./configure --with-regex=no +./configure --with-regex=yes But what do these new lines bring us in terms of coverage, except wasted time? The AC_ARG_WITH macro is tested in Autoconf already. --- /dev/null +++ b/tests/regex2.test +# Make sure AM_WITH_REGEX compiles and runs as advertised in +# documentation. +# See also sister test `regex3.test' Both of these tests seem so low-level, and yet so unlike what any user code would do, that I don't really see how they help the code. IOW, I fail to see how they ensure that the macro is actually useful for some package. Thanks, Ralf
Re: [PATCH] {maint} More tests on macro `AM_WITH_REGEX'.
* Stefano Lattarini wrote on Fri, Nov 12, 2010 at 09:12:53PM CET: On Friday 12 November 2010, Ralf Wildenhues wrote: This seems so obsoleted by gnulib that I don't think it is worth investing any more time into. In fact, I now think we should deprecate it, and then remove it. WDYT? Good idea. Let's deprecate it for 1.12, and remove it a couple of years later. Thanks, Ralf
Re: [PATCH] New tests on obsoleted usages of automake/autoconf macros.
* Stefano Lattarini wrote on Fri, Nov 12, 2010 at 08:57:05PM CET: How about * tests/backcompat6.test (Makefile.am): Grep the output from the test program, rather than diffing it, to avoid spurious failures on MinGW/MSYS due to LF vs. CRLF line endings. Sure, thanks! Ralf
bug#7374: Automake bug when moving files to different directory
Hi Török, thanks for the bug report. * Török Edwin wrote on Thu, Nov 11, 2010 at 01:11:44PM CET: Whenever I move a C/C++ file from a directory to another (and update Makefile.am), a subsequent 'make' fails because it is looking for the file in the old place (the .Plo dependency file actually). For exampling moving test1/Foo.c to test2/Foo.c results in this error: make: *** No rule to make target `test1/Foo.c', needed by `Foo.lo'. Stop. Confirmed. This is the deleted header file problem (discussed in the list archives, and in the manual), except that for you it applies to the primary source file, not included headers. For the headers we work around the issue by adding header.h: lines in the .Po files for each included header (non-ancient gcc versions do this for us, for other compilers depcomp does it). We don't do this for the primary source files. I think this is so that we get a sensible error from make when some primary source file isn't present (haven't checked archives on this yet, though). This is a bit annoying when it happens, because it breaks our buildbots, and have to login to each one and run make distclean manually (or zap the builddir) to fix it. How come this happens at all for your buildbots? Do they do incremental builds only, rather than full rebuilds from scratch? I'd expect bots to mostly do the latter, unlike developers while hacking. Fortunately we don't move around files that much (this is only 2nd time it occured in a few years, and 1st time I wrote a testcase, but forgot to file the bugreport). Good. So this isn't a pressing issue. I think that: - make clean should remove the dependency files if they're out of date/wrong That is unfortunately not possible, because make will barf if files included from the Makefile are missing. GNU make has '-include' for this, but there is no equivalent of that for portable make. This is the reason that config.status produces stub .Po files when they are not present. - rerunning configure or config.status should regen the dependencies properly, and not rely on some old, out-of-date dependencies Oh, we really believe in tracking dependencies on the fly for compilation, i.e., we try to avoid extra invocations of the compiler in order to compute dependency information (at least with capable compilers). Hope that helps. Cheers, Ralf
bug#7374: Automake bug when moving files to different directory
* Török Edwin wrote on Thu, Nov 11, 2010 at 09:10:56PM CET: On Thu, 11 Nov 2010 20:42:05 +0100 Ralf Wildenhues wrote: * Török Edwin wrote on Thu, Nov 11, 2010 at 01:11:44PM CET: I think that: - make clean should remove the dependency files if they're out of date/wrong That is unfortunately not possible, because make will barf if files included from the Makefile are missing. GNU make has '-include' for this, but there is no equivalent of that for portable make. This is the reason that config.status produces stub .Po files when they are not present. OK, then how about: - make clean deletes .Po/.Plo files, and invokes config.status with proper flags to produce the stub .Po files? Having the old .Po files around after a make clean isn't going to help speed up the build anyway since all the obj files are gone. True, but the above sounds quite ugly as well. Here's a better suggestion: use the subdir-objects automake option (you can add it to the options passed to AM_INIT_AUTOMAKE) and configure with --enable-maintainer-mode. That way the old .Po file will just not be read any more, and the maintainer mode will trigger the automake rerun that then causes the rules in Makefile to be successfully updated. Hope that is good enough for you. Cheers, Ralf
Re: [PATCH 1/7] Tests defs: various reorderings, some improvements.
* Stefano Lattarini wrote on Thu, Nov 11, 2010 at 01:00:47PM CET: On Thursday 11 November 2010, Ralf Wildenhues wrote: Thank for respinning. The patches are ok then, but I think you should take care that the newly-introduced `pwd` is replaced by the variable you later introduce for this (in the later patch, of course). Which newly-introduced pwd? There should be no such thing in these patches, if I'm not mistaken. Mistake of mine, I overlooked that this one: @@ -390,7 +395,9 @@ case $required in esac # Libtool cannot cope with spaces in the build tree. Our testsuite setup # cannot cope with spaces in the source tree name for Libtool and gettext -# tests. +# tests. Using just `pwd` for the check here is ok, since the further +# temporary subdirectory where the test will be run is ensured not to +# contain any space. case $testsrcdir,`pwd` in *\ * | *\*) Exit 77;; esac is treated in 2/7. Sorry about that. Thanks, Ralf
Re: [PATCH 0/7] Refactoring of testcases initialization code
* Stefano Lattarini wrote on Thu, Nov 11, 2010 at 02:41:40PM CET: On Sunday 07 November 2010, Stefano Lattarini wrote: Stefano Lattarini (7): Tests defs: various reorderings, some improvements. Tests defs: prefer $curdir over `pwd`. Tests defs: rename $curdir - $testbuilddir Tests defs: do not print message Running test $0 anymore. Tests defs: $testsbuilddir is now AC_SUBST'ed. Tests defs: new AC_SUBST'ed variable $top_testsbuilddir. Tests defs: move static definitions in a new file `minidefs'. I've pushed the patch to tests-init, with some amendings and respinnings suggested in various replies in the related thread. I still haven't merged tests-init into master, but I'd like to do that soon; is that OK for you? Yep, thanks! I'm looking at the remaining rebase next, in case you want to wait. Cheers, Ralf
Re: [PATCH] {tests-init} Tests defs: improve messages for skipped tests.
* Stefano Lattarini wrote on Thu, Nov 11, 2010 at 09:10:39PM CET: On Thursday 11 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Thu, Nov 11, 2010 at 02:52:06PM CET: @@ -228,11 +229,16 @@ do (echo foo $priv_check_temp) /dev/null 21 overwrite_status=$? rm -f $priv_check_temp - test $overwrite_status = 0 exit 77 + if test $overwrite_status = 0; then -eq seems more appropriate than = (more instances below). OK. Sorry for making you fix bugs that were there before BTW. +echo $me: this test shouldn't be run as root Please 2, several instances. I used stdout for consistency with messages like: echo $me: running $CC --version echo $me: running python -V But those aren't errors. I know it's a close call for the above messages, but for error messages, stderr is definitely right. But I have no strong feelings on this matter, so I went along with the 2 redirections throughout. Thanks. perl-threads) - # Skip with Devel::Cover: it cannot cope with threads. - test $WANT_NO_THREADS = yes exit 77 + if test x$WANT_NO_THREADS = xyes; then no need to quote `yes', and in practice, no need for x prefixing either, I would guess. Do you think we need to take care of malicious users? No, it's just for consistency. Because sometimes the idiom test x$foo = xbar is indeed required, I prefer to use it everywhere, instead of asking myself at every turn do I need to care for white spaces in $foo here? or do I need to care for leading hypens in $foo here?. That's all. Well, the quotes around bar are never required (except in Libtool and there only because out testsuite is too dumb to not flag the false positives). Do toy want me to use: test $WANT_NO_THREADS = yes anyway? No. You need to put double quotes around $WANT_NO_THREADS, because it can be empty. The rest is not a big deal either way, but if you want to avoid asking yourself at every turn, then I just suggest not changing existing code at that turn unless you see a good reason. ;-) tex) # No all versions of Tex support `--version', so we use # a configure check. - test -n $TEX || exit 77 + if test x$TEX = x; then test -n is portable here and more concise, $TEX will never start with a '-' character or be equal to '=' for any sane user. So let's please keep that. Well, we should use `test -z' at least, since the semantic of the check has been reversed. Also, `test -z' can sometimes be problematic too, and I tend to avoid it altogheter for the same consistency resons stated above. Do you want me to use `tezt -z' anyway here? Sure. @@ -285,6 +298,37 @@ do esac done The rest of the patch from here on below seems to only transpose testing of $required and testing of some other variable. In essence for the default case it turns one case statement into three (thus a minor slowdown), little code into more code, and I fail to see the advantage of the new ordering. What is the intention here? Giving precise resons about why the test was skipped. Ah; that's a good reason. Thanks. -case $testsrcdir,$testbuilddir in - *\ * | *\ *) exit 77;; + *' libtool '*|*' libtoolize '*) +if test x$libtool_found != xyes; then The old code was perfectly well quoted: in test $libtool_found = yes you would reliably and helpfully get a shell error if $libtool_found was erroneously unset. Also, we ensure that it could not start with '-'. True, but see the consistency reasons stated above. Do you want me to revert to the older (lack of) quoting anyway? Yes, please. Think of it as a check of your other changes in the code. ;-) Thanks, and please commit the patch when items are addressed, Ralf
Re: execvp: /bin/sh: Argument list too long
Hello Pippijn, * Pippijn van Steenhoven wrote on Mon, Nov 08, 2010 at 10:11:20PM CET: On Mon, Nov 08, 2010 at 09:56:52PM +0100, Ralf Wildenhues wrote: [1] On some systems this is not true; e.g., GNU make evades the limit on MSYS for this particular point, IIRC using a response file. Can automake do something similar? The dist files are always the same (well, they should be), so they can be written to an extra file, which is then piped into xargs or something. In principle: yes, when the list of files is completely known at automake run time. This would mean, no @substituted@ bits in that macro anywhere, no conditional bits, and you don't get to override macros at make run time like make DISTFILES='foo bar baz' These new limitations would not seem very harsh for most packages; especially for the distdir target, most conditionals are ineffective, and users are not likely to want to override them at make run time, but disallowing subtitutions would be a real limitation. Even just reordering the list of files might introduce bugs with some (admittedly fragile) setups, with packages that rely on dependency order (thus of course disallowing parallel execution) or that contain e.g., both FILE and ../sub/FILE in the list somewhere. (We do have measures in place to cope with FILE and $(srcdir)/FILE so the latter point should be really rare.) What version of GNU make are you using? There was an issue in GNU make 3.81 related to setting stack limits, that I believe is resolved in GNU make 3.82. I can't recall the details. I don't think it's that. It's that GNU make also requires the per-argument limit to be large, and IIRC that is still 128K on Linux (yes, speaking about the kernel only). I wrote about this before: http://thread.gmane.org/gmane.comp.gnu.make.bugs/4219 but my proposed hack back then was (understandably) not too popular, and I haven't gotten back to anything better yet. ;-) In other words, I can't make dist even with GNU make 3.82? What do you suggest, then? Well, you could try my patch from http://article.gmane.org/gmane.comp.gnu.make.bugs/4219 (append /raw to the URL to get it unmangled). I still think letting GNU make avoid the issue on Linux systems would be the easiest way out here. As already written, alternative workarounds include reorganizing your code a bit to have a bit more recursive makefile setup, so that each makefiles' list would remain below the limit. Cheers, Ralf
bug#7333: [PATCH] {maint} Fix a bug in variable concatanation with `+='.
* Glenn Morris wrote on Tue, Nov 09, 2010 at 08:34:23AM CET: Ralf Wildenhues wrote (on Mon, 8 Nov 2010 at 22:46 +0100): The commands above (Bcc:ed to control at debbugs) should merge and close both bugs. The (first) close didn't work, I think it was because your version number started with a `v', not a digit. The second close worked. Can that be fixed in debbugs? I would love to have both 'git describe' output as well as commit SHA1 strings be acceptable as version strings. git describe output starts with v but then contrains fairly much arbitrary characters as put in the last signed git tag. SHA1's are easier, and if the other is a problem then those would still be better than no version information, I guess. Thanks, Ralf
bug#7333: [PATCH] {maint} Fix a bug in variable concatanation with `+='.
* Glenn Morris wrote on Wed, Nov 10, 2010 at 09:46:01PM CET: Actually, that was probably too glib a response. The version number information is probably used in other places, and needs to be sortable so that the fixed/found commands can work. So I don't think arbitrary version strings can work. You could use the date of a commit perhaps. If that's the case, let's I'd say just live with it. Anyway better to send mail to NNN-done, where one can include arbitrary detail. Thanks for checking, Ralf
Re: More problems with `make -n' in automake-generated rules.
* Ralf Wildenhues wrote on Mon, Nov 01, 2010 at 10:18:55PM CET: Fix and document rules to not touch the tree with `make -n'. * doc/automake.texi (Multiple Outputs): Document the problem of modifications during dry-run execution, propose solution. * NEWS: Update. * automake.in (lang_vala_finish_target): Split recipe so the stamp file is not removed with GNU `make -n'. (lang_yacc_target_hook): Separate removal of parser output file and header remaking. * lib/am/lisp.am ($(am__ELCFILES)): Determine whether -n was passed to make, take care not to remove any files in that case. * lib/am/remake-hdr.am (%CONFIG_H%): Separate removal of %STAMP% file from induced remaking of config header. * tests/autohdrdry.test, tests/lispdry.test, tests/yaccdry.test: New tests. * tests/Makefile.am (TESTS): Update. This test needed a fixup, as yaccdry requires nonempty $YACC. Found by the NixOS Hydra, kudos to them! http://hydra.nixos.org/build/741504 The test could probably also be written without requiring bison (make -t or so), but I'd prefer to have the setup be realistic, that's more important than having coverage on every system out there. Pushed to maint. Thanks, Ralf Fix yaccdry.test failure: require bison. * tests/yaccdry.test: Require bison. Found by NixOS Hydra. 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
Re: [PATCH 2/7] Tests defs: prefer $curdir over `pwd`.
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:16:53PM CET: * tests/defs.in: We already save the value of `pwd` in $curdir early in the file, so there no need to recalculate it later, when the current working directory is not changed. OK. Thanks, Ralf
Re: [PATCH 4/7] Tests defs: do not print message Running test $0 anymore.
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:18:53PM CET: * tests/defs.in: Printing the message === Running test $0 at the beginning of each tests made sense when Automake used the old test-driver, which sent all the output directly to stdout/stderr. Now that the parallel test-driver is used, which saves output of each test in its correspoding log file, that old message is just useless noise. OK. It's not completely noise, as it still served as a guide to the eye when the ./defs preparation code ended and the actual test code started (but you broke that in an earlier patch in this patch series), when the test was run with 'sh -x ./test'. Thanks, Ralf
Re: [PATCH 3/7] Tests defs: rename $curdir - $testbuilddir
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:17:48PM CET: * tests/defs.in: Rename $curdir to $testbuildir, for clarity and consistency with $testsrcdir and $top_testsrcdir. OK. Thanks, Ralf
Re: [PATCH 5/7] Tests defs: $testsbuilddir is now AC_SUBST'ed.
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:19:55PM CET: * tests/defs.in ($testsbuilddir): Initialize statically with the value AC_SUBST'ed from @abs_builddir@, rather than dinamically with the value returned by `pwd`. dynamically You could also just write instead: * tests/defs.in ($testsbuilddir): Substitute from @abs_build...@. Add sanity check on $testsbuilddir, similar to those on $testsrcdir and $top_testsrcdir. OK. Thanks, Ralf
Re: [PATCH 6/7] Tests defs: new AC_SUBST'ed variable $top_testsbuilddir.
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:21:09PM CET: * tests/defs.in ($top_testsbuilddir): New variable, initialized with the value AC_SUBST'ed from @abs_top_build...@. Mostly for completeness and consistency with $testsrcdir and $top_testsrcdir. Let's add this only when we need it. Do we? Thanks, Ralf
Re: [PATCH 1/7] Tests defs: various reorderings, some improvements.
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:00:47PM CET: This is basically just a reordering patch, which should organize the code in `tests/defs.in' in a clearer and more rational way. * tests/defs.in: Reordered various snippets of code in a clearer way. Improved a couple of error messages, by reporting the test name in them. Some comments added. I cannot review this patch. Either just reordering, or just other changes, but not both in one patch please. Thanks, Ralf
Re: [PATCH 7/7] Tests defs: move static definitions in a new file `minidefs'.
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:29:27PM CET: Tests defs: move static definitions in a new file `minidefs'. minidefs is not a good name, as it is bound to not stay mini. How about defs-static or defs-init? (And yes, I'm shying away from renaming defs, that's just too big and churny a change for such a slight misnomer.) The new file is designed to be idempotent w.r.t. mutiple inclusions, s/designed/meant/, no? I don't see a design document. ;- and this will help us to cope better with e.g. generated tests and tests with complex setups, scaffoldings or indirections. What is scaffoldings? I think the first line of the summary text was completely sufficient. * tests/defs.in: Removed, it's contents split among ... its * tests/defs: ... this new file ... * tests/minidefs.in: ... and this new file. You need to mention the remaining changes here; e.g., that defs sources the other file now. * configure.ac (AC_CONFIG_FILES): Remove `tests/defs', add `tests/minidefs'. * configure.ac (AC_CONFIG_LINKS): Add `tests/defs'. * tests/Makefile.am ($(parallel_tests)): Update. ($(instspc_tests)): Likewise. * tests/.gitignore: Update. OK with those changes. Thanks, Ralf
Re: [PATCH 5/5] Tests defs: improve messages for skipped tests.
* Stefano Lattarini wrote on Wed, Sep 08, 2010 at 08:57:19PM CEST: * tests/defs.in: Give meaningful messages about the reasons of a test skip; this is especially useful as this file is run without verbose xtraces on. Related reorderings in the code and new comments. What happened to this patch in the new, rebased patch series? Was it already subsumed in some other series? Thanks, Ralf --- a/tests/defs.in +++ b/tests/defs.in @@ -261,6 +261,7 @@ do export GCJ echo $me: running $GCJ --version ( $GCJ --version ) || exit 77 + echo $me: running $GCJ -v ( $GCJ -v ) || exit 77 ;; g++) @@ -297,11 +298,16 @@ do (echo foo $priv_check_temp) /dev/null 21 overwrite_status=$? rm -f $priv_check_temp - test $overwrite_status = 0 exit 77 + if test $overwrite_status = 0; then +echo $me: this test shouldn't be run as root +exit 77 + fi ;; perl-threads) - # Skip with Devel::Cover: it cannot cope with threads. - test $WANT_NO_THREADS = yes exit 77 + if test x$WANT_NO_THREADS = xyes; then +echo $me: skip with Devel::Cover: it cannot cope with threads. +exit 77 + fi ;; python) # Python doesn't support --version, it has -V @@ -317,7 +323,10 @@ do (: $ro_dir_temp/probe) /dev/null 2/dev/null create_status=$? rm -rf $ro_dir_temp - test $create_status = 0 exit 77 + if test $create_status = 0; then +echo $me: support of read-only directories is required +exit 77 + fi ;; rst2html) # Try the variants that are tried in check.am. @@ -326,6 +335,7 @@ do echo $me: running $r2h --version $r2h --version break 2 done +echo $me: no proper rst2html program found exit 77 done ;; @@ -333,13 +343,16 @@ do # DejaGnu's runtest program. We rely on being able to specify # the program on the runtest command-line. This requires # DejaGnu 1.4.3 or later. - echo $me: running runtest --version + echo $me: running runtest SOMEPROGRAM=someprogram --version (runtest SOMEPROGRAM=someprogram --version) || exit 77 ;; tex) # No all versions of Tex support `--version', so we use # a configure check. - test -n @TEX@ || exit 77 + if test x'@TEX@' = x; then +echo $me: TeX is required, but it wasn't found by configure +exit 77 + fi ;; texi2dvi-o) # Texi2dvi supports `-o' since Texinfo 4.1. @@ -354,6 +367,37 @@ do esac done +# Using just `$testbuilddir' for the check here is ok, since the +# further temporary subdirectory where the test will be run is +# ensured not to contain any whitespace character. +case $testbuilddir in + *\ *|*\*) +case $required in + *' libtool '* | *' libtoolize '* ) +echo $me: libtool/libtoolized cannot cope correctly +echo $me: with spaces in the build tree. +exit 77 +;; +esac +;; +esac + +# This test is necessary, although Automake's configure script bails out +# when $srcdir contains spaces. This is because $testsrcdir is in not +# configure-time $srcdir, but is instead configure-time $abs_srcdir, and +# that is allowed to contain spaces. +case $testsrcdir in + *\ * |*\ *) +case $required in + *' libtool '* | *' libtoolize '* | *' gettext '* ) +echo $me: our testsuite setup cannot cope correctly with spaces +echo $me: in the source tree for libtool/gettext tests. +exit 77 +;; + esac + ;; +esac + # We might need extra macros, e.g., from Libtool or Gettext. # Find them on the system. # Use `-I $top_testsrcdir/m4' in addition to `--acdir=$top_testsrcdir/m4', @@ -384,16 +428,20 @@ case $required in fi done case $required in - *' libtool '* | *' libtoolize '* ) test $libtool_found = yes || exit 77;; - *' gettext '* ) test $gettext_found = yes || exit 77;; -esac -# Libtool cannot cope with spaces in the build tree. Our testsuite setup -# cannot cope with spaces in the source tree name for Libtool and gettext -# tests. Using just `$testbuilddir' for the check here is ok, since the -# furter temporary subdirectory where the test will be run is ensured not -# to contain any space. -case $testsrcdir,$testbuilddir in - *\ * | *\ *) exit 77;; + *' libtool '*|*' libtoolize '*) +if test x$libtool_found != xyes; then + echo $me: libtool/libtoolize is required, but libtool.m4 wasn't + echo $me: found in directories $aclocaldir $extra_includes + exit 77 +fi +;; + *' gettext '*) +if test x$gettext_found != xyes; then + echo $me: gettext is required,
Re: [PATCH 7/7] Tests defs: move static definitions in a new file `minidefs'.
* Stefano Lattarini wrote on Thu, Nov 11, 2010 at 12:16:27AM CET: On Wednesday 10 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:29:27PM CET: Tests defs: move static definitions in a new file `minidefs'. [...] * tests/defs: ... this new file ... * tests/minidefs.in: ... and this new file. You need to mention the remaining changes here; e.g., that defs sources the other file now. Is this OK? * tests/defs.in: Removed, its contents split among ... * tests/defs-static.in: ... this new file ... * tests/defs: ... and this new file, including the former. Sure, if that really is all that was changed. Thanks, Ralf
Re: [PATCH 1/7] Tests defs: various reorderings, some improvements.
* Stefano Lattarini wrote on Thu, Nov 11, 2010 at 12:37:23AM CET: Well, the patch is almost just code reordering, with the very minor exceptions that: 1. in the older version, some error messages could be printed before `$me' was defined, so they couldn't use it; now `$me' is defined early, so those error messages has been amended to include it; 2. in the older version, a test might be skipped from within code in `tests/defs' *after* the exit trap was installed, so a call to Exit 77 was in order; now the skips only happens before the installation of the exit trap, so exit 77 is enough; 3. some comments has been slighty adjusted and extended, because the act of reordering the code suggested them to me. Anyway, none of these additional minor changes is really required to make the new `tests/defs.in' work correctly, so I agree that they should have been done in follow-up patches. I've respin and split my patch to do so (see the attached four patches). Thank for respinning. The patches are ok then, but I think you should take care that the newly-introduced `pwd` is replaced by the variable you later introduce for this (in the later patch, of course). Thanks, Ralf
Re: Silencing doxygen output
Hi Erik, * Erik de Castro Lopo wrote on Wed, Nov 10, 2010 at 12:45:03PM CET: I'm using AM_SILENT_RULES([yes]) to silence make output and I'm pretty happy with it. However, I have a doxygen command in a Makefile.am: doxygen reference.doxygen and I can't figure out how to silence it. target: deps $(AM_V_GEN)doxygen reference.doxygen There is more information and a more complex example in the documentation at 'info Automake --index silent-rules'. Cheers, Ralf
bug#7364: Typo in manual
Hi Reuben, * Reuben Thomas wrote on Wed, Nov 10, 2010 at 03:24:14PM CET: Script are not distributed by default - Scripts are not distributed by default Thanks, this has already been fixed in the git tree of Automake. Cheers, Ralf
Re: [FYI] Fix bug in test `backcompat4.test' (stale autom4te cache)
* Stefano Lattarini wrote on Tue, Nov 09, 2010 at 12:30:56PM CET: Wouldn't this report have been better suited for bug-automake, especially now that you've gone through the hassle of setting that up as a real bug tracker? Sure, I guess. backcompat4.test is failing for me, see below. This is with Autoconf 2.68. Yes, I'm experiencing similar non-deterministic failures: I think it's due to the fact that backcompat4.test don't remove the old autom4te cache directory before re-running aclocal and automake. With the attached patch applied, I've not encounterd the intermittent failure anymore in 100 tries. So I've applied the patch as a bug-fixing patch (as explained in HACKING), merged to master, and pushed. Thanks; I agree. Ralf
Re: LTFCCOMPILE and FCFLAGS_f90
Hi Rhys, * Rhys Ulerich wrote on Tue, Nov 09, 2010 at 05:58:23PM CET: I'm having a miserable time trying to figure out when LTFCCOMPILE picked up FCFLAGS_f90 per AC_FC_SRCEXT. Anyone know offhand what tool versions I need? No, but the automake/NEWS file tells me that is new in 1.11. :-) Getting FCFLAGS_f90 handling right is important for gfortran pre-4.4's need for -x f95-cpp-input to play nice with libtool. Otherwise that flag treats all the object files as Fortran sources and (not surprisingly) blows up. :) Indeed. Hope that helps. Cheers, Ralf
Re: [Automake-commit] [SCM] GNU Automake branch, master, updated. v1.11-414-g3dffb01
[ moving from automake-commit ] Hi Stefano, * Stefano Lattarini wrote on Sun, Nov 07, 2010 at 04:37:15PM CET: This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Automake. [...] commit 1e460312d79fe15170e7519fb785e132ac7293fb Merge: 4555c81 657ba88 Author: Stefano Lattarini stefano.lattar...@gmail.com Date: Sun Nov 7 11:50:06 2010 +0100 Merge branch 'tests-misc-fixes-1' Conflicts: tests/Makefile.am tests/Makefile.in For what little it's worth, I tend to remove the Conflicts: section of the generated merge commit log entry when I have successfully dealt with any conflicts. It's no big deal either way really, but I find it more distracting than helpful. Cheers, Ralf
Re: execvp: /bin/sh: Argument list too long
Hello Pippijn, * Pippijn van Steenhoven wrote on Mon, Nov 08, 2010 at 04:55:45PM CET: I looked through the mailing list archives and found several questions and proposed solutions related to this problem: - Split up file lists so several rules are generated: http://lists.gnu.org/archive/html/automake/2004-11/msg00106.html - What is your env's size? http://lists.gnu.org/archive/html/automake/2009-08/msg00027.html - It will fail. In other words Sorry, can't fix? http://lists.gnu.org/archive/html/automake/2007-02/msg00013.html Also, we wrote a short section in the manual about this (in recent versions): info Automake Length Limitations My problem is that I can not make dist in one project and not make check in another project. Both have a large number of tests. The one where make check fails has a few more tests, but make dist will fail there, as well. One workaround is to put tests in more than one directory, with more than one Makefile.am. Yes, it is ugly, I know. Another is to require non-VPATH builds on those systems with the most severe restrictions, such as MSYS and IRIX (if you can't convince root to increase the limit). What are the plans on fixing this? We'll fix what we can fix. Without GNU make-specifics, that is hard. One thing I'd definitely like to see done is allowing multiple parallel-tests test suites in one Makefile.am, so you can still have a nonrecursive setup. That may mean that 'make dist' still fails, but my hope is that is not needed to work on every platform. Would that be sufficient for your needs? Are there any? Autoconf already checks for the maximum argument length, It's a configure check from a Libtool macro that does that, actually. but since by that time, Makefile.in is already generated, it can't help. Maybe storing the list of dist files and check files in a different file and reading this with xargs $file would help. One problem is that with many constructs, automake would like to know the exact set of files it deals with. We can try to deviate from that in some places but my guess is that will always look like a hack that avoids some but not all issues. One other strategy we maybe could implement is alternative GNU make-specific rules that avoid limitations by dealing with files with make functions. That is usually doable, but doing this consistently will be quite some work and cause quite some duplication in the Makefile.in. I don't have current plans to pursue this; you can see e.g., the write_entries_to_file macro in the gcc/Makefile.in file in the GCC tree for how this can be done in principle. Cheers, Ralf
Re: execvp: /bin/sh: Argument list too long
* Pippijn van Steenhoven wrote on Mon, Nov 08, 2010 at 09:01:12PM CET:
On Mon, Nov 08, 2010 at 08:03:06PM +0100, Ralf Wildenhues wrote:
Also, we wrote a short section in the manual about this (in recent
versions):
info Automake Length Limitations
I hadn't seen that, before. Now I read it, I noticed something:
Automake itself employs a couple of strategies to avoid long command
lines. For example, when ‘${srcdir}/’ is prepended to file names, as
can happen with above $(data_DATA) lists, it limits the amount of
arguments passed to external commands.
Why doesn't it do that, always? Is the performance hit too large?
That's not the point.
With code like this:
foo = some long list of files
target: $(foo)
$do_something_with $(foo)
the fork for the shell to $do_something_with may fail already if $(foo)
is too long[1]. The above strategy is only eligible for issues when
$(foo) itself is short enough to be expanded, but prepending $(srcdir)/
everywhere *will* make it go over the limit.
[1] On some systems this is not true; e.g., GNU make evades the limit on
MSYS for this particular point, IIRC using a response file.
What are the plans on fixing this?
We'll fix what we can fix. Without GNU make-specifics, that is hard.
One thing I'd definitely like to see done is allowing multiple
parallel-tests test suites in one Makefile.am, so you can still have a
nonrecursive setup. That may mean that 'make dist' still fails, but
my hope is that is not needed to work on every platform.
Would that be sufficient for your needs?
I'd be happy if make dist worked on my system, but it doesn't and I
didn't find a way to make it work, yet (any suggestions here?).
You need to specify exactly where it fails if my previous suggestions
were not enough. Showing the Makefile.am in question would help too.
but since by that time, Makefile.in is
already generated, it can't help. Maybe storing the list of dist files
and check files in a different file and reading this with xargs $file
would help.
One problem is that with many constructs, automake would like to know
the exact set of files it deals with. We can try to deviate from that
in some places but my guess is that will always look like a hack that
avoids some but not all issues.
Automake can know the maximum set of files it deals with. Wouldn't that
help, already?
Well, that's not the hard part. automake would need to rewrite long
lists of files into separate variables, and use them in separate
recipes. Generating sets of such recipes for several targets is
probably doable, but not straight-forward. Throw conditionals and
@substed@ parts into the mix, and it can easily get a mess.
* Paul Smith wrote on Mon, Nov 08, 2010 at 09:03:59PM CET:
On Mon, 2010-11-08 at 21:01 +0100, Pippijn van Steenhoven wrote:
I am root on my (Linux) system and I set the stack size to unlimited.
The libtool macro reported a few billion (or something other really
large) for maximum argument list length, bash also agreed (it easily
executed the distdir target when copied into a bash script), but
make doesn't.
What version of GNU make are you using? There was an issue in GNU make
3.81 related to setting stack limits, that I believe is resolved in GNU
make 3.82. I can't recall the details.
I don't think it's that. It's that GNU make also requires the
per-argument limit to be large, and IIRC that is still 128K on Linux
(yes, speaking about the kernel only). I wrote about this before:
http://thread.gmane.org/gmane.comp.gnu.make.bugs/4219
but my proposed hack back then was (understandably) not too popular,
and I haven't gotten back to anything better yet. ;-)
Cheers,
Ralf
bug#7333: [PATCH] {maint} Fix a bug in variable concatanation with `+='.
merge 7333 7345 tags 7333 + patch close 7333 v1.11-222-g7a020d6 thanks * Stefano Lattarini wrote on Sun, Nov 07, 2010 at 03:26:52PM CET: Now, should I also try to close the bug #7333 on debbugs? The instruction at http://debbugs.gnu.org/Developer.html seems quite clear about how to do so, so I think I can manage to get it right. BTW, Ouch! I see that my previous reply presenting the patch has erroneously opended a new, spurious bug report (#7345) in the tracker! Ralf, could you please you close that report as invalid? Not sure how that happened, probably the Subject: change. The commands above (Bcc:ed to control at debbugs) should merge and close both bugs. Cheers, Ralf
bug#7333: [PATCH] {maint} Fix a bug in variable concatanation with `+='.
Hello Stefano, Andy, * Stefano Lattarini wrote on Sat, Nov 06, 2010 at 06:10:44PM CET: On Friday 05 November 2010, Stefano Lattarini wrote: I can confirm the bug with latest automake (from git master), with a much-reduced minimal testcase (see attachment). I still haven't looked for an explanation or a fix, though. I've manged to find a very simple fix for the bug (see attached patch). OK to apply to maint? OK if it passes the whole testsuite. Thanks to both of you, for the report and the fast fix! Cheers, Ralf From b8de299295e081909c6d0a8a1cef957b337e3732 Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sat, 6 Nov 2010 12:46:52 +0100 Subject: [PATCH] Fix a bug in variable concatanation with `+='. * lib/Automake/VarDef.pm (append): Remove extra backslash-escaped newlines from the end of the variable's content, before appending to it. * tests/pluseq11.test: New test, exposing the bug. * tests/Makefile.am (TESTS): Update. Reported by Andy Wingo.
Re: More problems with `make -n' in automake-generated rules.
* Stefano Lattarini wrote on Sat, Nov 06, 2010 at 08:23:30PM CET: On Saturday 06 November 2010, Stefano Lattarini wrote: On Saturday 06 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sat, Nov 06, 2010 at 05:52:57PM CET: Hi Ralf, I've just spotted a bug in the patch ... [...] ... here (missing fi). It causes a failure in `vala2.test'. I'll install a fix later if you don't beat me (right now I'm doing other testing, and prefer not to be sidetracked by this issue). That's what I get for forgetting one testsuite addition. Thanks for tracking this down, and please push the fix, ideally together with a new test Is a new test really needed? After all, I noticed the bug because it broke the pre-existing `vala2.test'... Ouch. That means I either messed up testing somehow, or pushed an old version of the patch. Probably the latter, as I remember fixing a vala related bug. I've gone ahead and comitted the fix without adding a new testcase. Please let me know if you still think a testcase addition would be valuable, in which case I'll add it in a follow-up patch. No, in that case it is fine as is. Thanks. Cheers, Ralf
Re: [PATCH] Modernize, improve and/or tweak various test scripts.
Hi Stefano,
* Stefano Lattarini wrote on Mon, Sep 13, 2010 at 11:22:37AM CEST:
I updated the patch slighty (see test `depdist.test') to follow the
emerging principle of preferring semantic tests to grepping tests
in the Automake testsuite.
OK with nits addressed.
and in another mail:
Pinging this patch again, following this:
http://lists.gnu.org/archive/html/automake-patches/2010-11/msg3.html
There should be no need to rebase the patch (which is based off of maint),
so that I should just be able to merge it into master from the copy in my
local automake repository (maybe fixing the date of the ChangeLog entry
after the merge?)
Yes, sure.
Thanks,
Ralf
From b6d67d34e440ef275f77c955a84658fb70c160f0 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Mon, 21 Jun 2010 18:07:09 +0200
Subject: [PATCH] Modernize, improve and/or tweak various test scripts.
* tests/stamph2.test: Improve m4 quoting in `configure.in', and
prefer trailing `:' over trailing `Exit 0'.
* tests/syntax.test: Escape literal dots in grep regexps.
* tests/copy.test: Enable `errexit' shell flag. Extend test by
checking with `test' utility that the script `install-sh' is
copied, but not symlinked.
* tests/depdist.test: Move setting of `errexit' shell flag earlier
in the script (just after inclusion of ./defs). Avoid obsoleted
constructs in generated `configure.in'. Prefer to do our checks
by running configure and make over grepping Makefile.in.
* tests/target-cflags: Move setting of `errexit' shell flag
earlier in the script (just after inclusion of ./defs). Use the
`configure.in' stub created by `./defs', rather than writing it
from scratch.
* tests/target-clash: Do not uselessly run autoconf.
* tests/ctarget1.test: Renamed ...
Please don't rename tests unless for a very good reason, and
please don't reuse names from tests that have been removed.
In case there is ever a merge across such a rename, git may
get confused without reason, and if there are automatic regression
testers they might think that there is a regression where there is
none, or vice versa.
* tests/cond1.test: ... to this. Use the `configure.in' stub
created by `./defs', rather than writing it from scratch.
Move setting of `errexit' shell flag earlier in the script (just
after inclusion of ./defs). Other minor cosmetic changes.
* tests/Makefile.am (TESTS): Updated.
--- a/tests/depdist.test
+++ b/tests/depdist.test
@@ -17,40 +17,60 @@
# Make sure depcomp is found for the distribution.
# From Eric Magnien.
+required=gcc # FIXME: any C compiler should be ok!
Why this? There is nothing in the test that requires GCC.
You can drop this line AFAICS.
. ./defs || Exit 1
+set -e
+
rm -f configure.in
mkdir config
for i in *; do
- if test $i != config; then
- mv $i config
+ if test $i != config; then
+ mv -f $i config
fi
done
-cat configure.in 'END'
-AC_INIT(subdir/foo.c)
-AC_CONFIG_AUX_DIR(config)
-AM_INIT_AUTOMAKE(nonesuch, nonesuch)
+cat configure.in END
+AC_INIT([$me], [1.0])
+AC_CONFIG_AUX_DIR([config])
+AM_INIT_AUTOMAKE
AC_PROG_CC
-AC_OUTPUT(subdir/Makefile Makefile)
+AC_CONFIG_FILES([subdir/Makefile Makefile])
+AC_OUTPUT
END
cat Makefile.am 'END'
SUBDIRS = subdir
+check-local: test1 test2
+.PHONY: test1 test2
+test1:
+ echo ' ' $(DIST_COMMON) ' ' | grep '[ /]config/depcomp '
+test2: distdir
+ ls -l $(distdir)/*
+ test -f $(distdir)/config/depcomp
END
mkdir subdir
-: subdir/foo.c
+cat subdir/foo.c 'END'
+int main(void)
+{
+ return 0;
+}
+END
cat subdir/Makefile.am 'END'
bin_PROGRAMS = foo
foo_SOURCES = foo.c
END
-set -e
-
$ACLOCAL
-$AUTOMAKE --add-missing
$AUTOCONF
-grep config/depcomp Makefile.in
+$AUTOMAKE --add-missing
+
+./configure
+
+$MAKE check
+$MAKE distcheck
+
+:
[...]
Re: [PATCH] Modernize, improve and/or tweak various test scripts.
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 11:18:49AM CET: On Sunday 07 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Mon, Sep 13, 2010 at 11:22:37AM CEST: * tests/ctarget1.test: Renamed ... Please don't rename tests unless for a very good reason, The good reason is IMHO that the name `ctarget1.test' is misleading w.r.t. the testcase's content. Hmm, well, maybe. and please don't reuse names from tests that have been removed. I didn't (we had alredy agreed that this would be bad practice); to verify that I'm speaking truth, try: $ git lgl master -- tests/cond1.test There should be no output (works for me). The test might not ever have made it to revision control, or it might have been in a non-merged branch only (so use --all to look). In case of doubt, at least use a name not likely to have been used before. Anyway cond1 also hints me that this is a very old test. So, ok to proceed with the rename? Please use a new name if you must. Thanks, Ralf
Re: [PATCH] Modernize, improve and/or tweak various test scripts.
* Stefano Lattarini wrote on Sun, Nov 07, 2010 at 11:44:44AM CET: On Sunday 07 November 2010, Ralf Wildenhues wrote: The test might not ever have made it to revision control, In this case I don't see any problem, no? Unless it's in a personal git clone only (not likely with existing history from CVS, but in general). So, ok to proceed with the rename? Please use a new name if you must. I used the new name `cond-basic.test' (again, git log --all tells me that it is safe). Thanks. I will be off-net soon so will only be able to continue review tomorrow night at the earliest. Cheers, Ralf
Re: [PATCH] {maint} Fix a bug in variable concatanation with `+='.
Hello Stefano, Andy, * Stefano Lattarini wrote on Sat, Nov 06, 2010 at 06:10:44PM CET: On Friday 05 November 2010, Stefano Lattarini wrote: I can confirm the bug with latest automake (from git master), with a much-reduced minimal testcase (see attachment). I still haven't looked for an explanation or a fix, though. I've manged to find a very simple fix for the bug (see attached patch). OK to apply to maint? OK if it passes the whole testsuite. Thanks to both of you, for the report and the fast fix! Cheers, Ralf From b8de299295e081909c6d0a8a1cef957b337e3732 Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sat, 6 Nov 2010 12:46:52 +0100 Subject: [PATCH] Fix a bug in variable concatanation with `+='. * lib/Automake/VarDef.pm (append): Remove extra backslash-escaped newlines from the end of the variable's content, before appending to it. * tests/pluseq11.test: New test, exposing the bug. * tests/Makefile.am (TESTS): Update. Reported by Andy Wingo.
Re: [FYI] {master} Fix potential bug in generated tests `instpc-*.test'. (was: Re: tests updates)
* Stefano Lattarini wrote on Fri, Nov 05, 2010 at 09:21:28PM CET: Nonetheless, there was still a potential bug (introduced by the merge) lurking in there, which didn't manifest itself because, by sheer luck, the Automake parallel test driver worked around it (by exporting srcdir=$(srcdir) in the tests' environment). After some testing, I pushed the attached patch, which should fix the bug. Thanks. Cheers, Ralf From 0c615cdc89beb544dedc7ee665e9e68e86f3468c Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Fri, 5 Nov 2010 21:14:30 +0100 Subject: [PATCH] Fix potential bug in generated tests `instpc-*.test'. This bug is due to the changes introduced by the recently-merged tests-init branch. In that branch, `tests/defs' didn't define anymore `$srcdir', instead defininig directly `$testsrcdir'; but the generated tests were using `$srcdir', hence the bug. Luckily, since the Automake parallel test driver automatically exports `srcdir' to a proper value, that prevented the bug from manifesting itself. * tests/Makefile.am ($(instspc_tests)): In the generated test scripts, use `$testsrcdir', not `$srcdir'.
Re: adding conditionally a c++ file implies static linking with g++
Hi Vincent, * Vincent Torri wrote on Fri, Nov 05, 2010 at 04:56:55PM CET: foo_SOURCES = bar1.c if MY_COND foo_SOURCES += bar2.cpp else foo_SOURCES += bar2.c endif One told me on that ML that it is normal that automake uses g++ for linking, even if MY_COND is not verified. One possible way to work around that is redefining rules of linking, according to the value of MY_COND. Something like (maybe not 100% correct) : if MY_COND foo_la-bar2.lo: bar2.cpp $(LTCXXCOMPILE) blah blah blah else foo_la-bar2.lo: bar2.c $(LTCOMPILE) blah blah blah endif Is there something more elegant than doing that ? Not really. I agree that it's kind of ugly, but what's even more, there are uses relying on something like this to happen: it was actually recommended to do e.g., if COND_FALSE nodist_foo_SOURCES += force-c++-linker.cc endif so I'm afraid you might have to live with a workaround. You can set foo_LINK for linking. Hope that helps. Cheers, Ralf
bug#7336: Failure on test parallel-tests5.test
* Lluís Batlle i Rossell wrote on Fri, Nov 05, 2010 at 01:36:28PM CET: On Mon, Nov 01, 2010 at 07:41:12PM +0100, Lluís Batlle i Rossell wrote: On Mon, Nov 01, 2010 at 07:07:48PM +0100, Ralf Wildenhues wrote: [ http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/5061 ] Ralf says that something changed about syscall restarting in linux 2.6.36, so it can be a problem in linux. I hope he will investigate that and keep all of us aware. I'll try linux 2.6.35 meanwhile. Fixed! Ralf and Al Viro found the kernel problem, made evident in the release 2.6.36 for mips only. Fixed here: http://git.linux-mips.org/?p=linux.git;a=commit;h=915bcf007cbf9370fa0f3a57b27cf7fdc45b3964 I reported to automake because it was the very only part of the system failing. Thanks for reporting and having this tracked down, I'm closing the Automake bug. Cheers, Ralf
Re: More problems with `make -n' in automake-generated rules.
Hi Stefano,
* Stefano Lattarini wrote on Sat, Nov 06, 2010 at 05:52:57PM CET:
Hi Ralf, I've just spotted a bug in the patch ...
- $output_rules .= \$(srcdir)/$headerfile:
\$(srcdir)/${derived}_vala.stamp\n.
- \...@if test -f \$@; then :; else \\\n.
- \t rm -f \$(srcdir)/${derived}_vala.stamp; \\\n.
- \t \$(am__cd) \$(srcdir) \$(MAKE) \$(AM_MAKEFLAGS)
${derived}_vala.stamp; \\\n.
- \tfi\n;
+ $output_rules .= \$(srcdir)/$headerfile:
\$(srcdir)/${derived}_vala.stamp\n
+ . \...@if test -f \$@; then :; else rm -f
\$(srcdir)/${derived}_vala.stamp; \n
... here (missing fi). It causes a failure in `vala2.test'.
I'll install a fix later if you don't beat me (right now I'm doing other
testing, and prefer not to be sidetracked by this issue).
That's what I get for forgetting one testsuite addition. Thanks for
tracking this down, and please push the fix, ideally together with a
new test (but better fixed without than nothing).
Cheers,
Ralf
bug#7328: parallel installation ignores deps between libtool libraries
Hi Andy, * Andy Wingo wrote on Thu, Nov 04, 2010 at 04:19:55PM CET: lib_LTLIBRARIES = libfoo.la plugindir = $(libdir)/gstreamer-0.10 plugin_LTLIBRARIES = bar.la bar_la_LIBADD = libfoo.la Obviously we are missing some sources here, but it suffices to show the parallel installation bug: there is a race between relinking the installed bar.la and the installed libfoo.la. It could be that libfoo.la isn't there yet. Yep; long-standing bug. We've pondered about strategies to fix it before, but no full solution yet. Here's a dirty workaround for the moment: install-pluginLTLIBRARIES = install-pluginLTLIBRARIES $(install-pluginLTLIBRARIES): install-libLTLIBRARIES Thanks for the report, Ralf
Re: tests updates
* Stefano Lattarini wrote on Thu, Nov 04, 2010 at 01:03:17PM CET: On Wednesday 03 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Wed, Nov 03, 2010 at 02:27:47PM CET: Just one question: what about the already-existing tests-init branch? Should I try to bring it to a point where it can be easily merged into master, and then forget about it, or should it continue to live parallel to master? Right now the branch looks like its changes would be fairly safe to merge to master, but also, it would mean that sharing testsuite patches between branch-1.11 and master may become a bit more cumbersome. So I'd say it depends a bit on where you want to go with this in the long run. Well, I'd like to: 1. reorganize the code in tests/defs.in in a more rational way (basically just a reordering of the code); Seems like a good idea. 2. (re)introduce the `run_command' function and use it throughout; I like it but before it can be merged it needs test exposure on Tru64/OSF, IRIX, and Solaris at least, ideally also AIX and HP-UX. You should be able to test on these systems in the near future, hopefully. 3. make it easier for the user to override the aclocal search path in the testsuite (a new pending patch from Paolo Bonzini could help with this); Why would the user need to mess with our testsuite? Oh, is this so Libtool testing works with distcheck and with unusual setups? 4. improve requirements' declaration in Automake test scripts, and make it easier to run the Automake testsuite using different C, C++ and Fortran compilers, without leaning too much towards the GNU compilers as it does now. This is a noble goal; I support it in a way that tests which are aimed at showing off Automake API which is supposed to be portable to different compilers, should also work with different compilers. Tests which are aimed at verifying more internal things do not need to be made artificially portable to external tools. Also, we should strive to not make ourselves too dependent on bugs in Autoconf or Libtool; while that can be helpful to uncover bugs in those tools, it also means that we make ourselves liable to timely fixes, or version tests and all. These major changes would be interspesed with minor code cleanups and refactoring, such as (to list a few) avoiding to leak temporary variables from `tests/defs' into the test scripts, renaming `$curdir' to (say) `$testbuilddir' for better clarity, and improve the messages from skipped tests. The minor cleanups sound ok, with the caveat that they have good chances of breaking merges, or test suite additions coming from the stable branch. It is thus a good idea not to change things gratuitously here, and it may be prudent to do defs API changes in a branch off of maint, so it can be merged into other active branches before they are merged into master. We can easily move to a strategy of having new testsuite stuff added to master only by default, and only care about branch-1.11 for fixing existing regressions and serious bugs, which would probably make the situation easier. Yes, I'd like to go this way. OK then. Of course there are other active branches too, that shouldn't have a harder-than-necessary time. Ideally, all the tests that work with current `tests/defs' should continue to work with the new one; the only problem might be that some new tests committed to another branch might cause *maintcheck* failures when merged to master, but that is not a big deal IMHO, and easily fixed anyway. OK. We could treat merges similarly to patches in announcing the intention to merge 72h before the fact, in those cases where there is doubt over the merge (or the precise point at which a merge should be done). This won't be necessary if we stick to master for tests extensions and refactoring. Well, don't let the above paragraph of mine be incentive to use less branches. That's not what I intended. Doing things in separate branches *when appropriate* is good! I must admit that I don't have all that much experience with merges of longer-term branches done by more than one person; one alternative would be that you suggest the merge and I do it (if that works out). Testing such merges usually requires a bit of additional work, in that both branches need to be checked for global changes that need adjusting in the respective other branch. Let's see how this works out. In the end, are you OK with having me to merge test-init to master right away, and do future testsuite work on master only? Yes. Thanks, Ralf
Re: [PATCH v2] Overhauled and modularized tests in `instspc.test'.
* Stefano Lattarini wrote on Wed, Nov 03, 2010 at 08:47:54PM CET: On Wednesday 03 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Wed, Nov 03, 2010 at 03:10:30PM CET: Pinging the patch again, following this: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg3.html Note that this patch is based off of master, not of maint, for reasons stated here: http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00180.html OK to push? Hmm, I didn't have this one on my radar any more. I think that's because in: http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00172.html I OKed the patch with nits addressed. There was some more discussion about things after that, but AFAICS you did not post a new full patch. Yes, because you told me once (cannot remember exactly when) that if I addressed objections from a reviwer exactly in the way suggested by him, there was no need to re-post a full amended patch. Sure; when I say OK with nits addressed then I mean that you don't need to ask for approval again after fixing the nits; you can just go ahead and commit the patch. If OTOH you would like another review, then that is very much helped by seeing an updated version of the patch. ;-) Also, you said that this patch was somewhat invasive and required some more testing, so I did the all the testsing I could before asking for the final blessing: http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00192.html http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00223.html Which is all good. Thanks. If you'd like me to take another look, please post the patch as you intend to push it. There should be no need of this, as the patch is unchanged except for rebasing (which triggered no conflicts, and left the testsuite pass). Well, then feel free to go! :-) Also, in above message I suggested an optimization of your patch; please indicate whether you intend to work on it. Yes, I was planning to do that (in a temporary branch) after the present patch is applied. Cool. Thank you, Ralf
Re: More problems with `make -n' in automake-generated rules.
* Stefano Lattarini wrote on Wed, Nov 03, 2010 at 06:48:16PM CET: Hello Ralf. Again, just a couple of nits w.r.t. the test cases... Thanks; but I didn't mean to actually commit the second patch (just in case that wasn't clear). That said, I'll reply to your comments inline. On Monday 01 November 2010, Ralf Wildenhues wrote: --- /dev/null +++ b/tests/remakedry.test @@ -0,0 +1,82 @@ +# Make sure GNU `make -n' doesn't trigger file updates when Makefile +# is out of date. + +# The subdir rebuilding rules rely on GNU make automatically updating +# the makefile and its prerequisites (through am--refresh). +required=GNUmake Why requiring GNU make here? After all, if a make implementation does not implement automatic Makefile-rebuild rules, it should trivially pass this test, and if implements them, it makes sense to run this test on it too. But that requires me to think about the test again: was this really meant to test portable code? The rebuilding rules, esp. the am--refresh trick, rely on GNU make-specifics, and special-casing some test of it just because it may or may not happen to trigger the specifics doesn't seem robust. I don't want the next small patch to this test cause a failure for non-GNU make, a failure I'm really not interested in in this test. Does that make sense? +cat Makefile.am 'END' +SUBDIRS = sub +END +mkdir sub +: sub/Makefile.am + +$ACLOCAL +$AUTOMAKE +$AUTOCONF +./configure +$MAKE + +# The toplevel rule is not problematic, as it is not recursive. +$sleep +touch Makefile.in +$sleep Is this second sleep really needed? More instances below. Definitely is. I want Makefile to be strictly newer so that ls -1t is guaranteed to work not because of locale ordering but because of different time stamps. +$MAKE -n Makefile +test `ls -1t Makefile Makefile.in | sed 1q` = Makefile.in Waht about using here the `is_newest' function provided by `tests/defs'? That would be a viable alternative that would also allow to ditch the second sleep, I guess (untested). +# Go through contortions to avoid GNU make's first, internal rebuild Makefile +# even in dry mode cycle in the recursive (am--refresh) part. +(cd sub $MAKE -n Makefile AM_MAKEFLAGS=-n Makefile) I'd add a || Exit 1 here, just to be sure w.r.t. shells with buggy `set -e'. What bug would you be trying to work around with it? One more intance below. +test `ls -1t sub/Makefile config.status | sed 1q` = config.status +(cd sub $MAKE Makefile) +test `ls -1t sub/Makefile config.status | sed 1q` = sub/Makefile + +: Cheers, Ralf
Re: [PATCH] {maint} Document in detail some limitations of aclocal.
Hello, * Stefano Lattarini wrote on Thu, Nov 04, 2010 at 08:47:47PM CET: I've gone ahead and documented this non-obvious limitation, and another similar one regarding AC_DEFUN. See the attached patch. Ralf, ok to apply to maint? There are a couple of things I don't like with the principle of this patch: hard-coding limitations in the testsuite, and hard-coding limitations and presenting them as such in the manual. The latter makes the project look bad, the other two are a maintenance hassle once and if the code is improved. We might even have to remove the section in the manual once aclocal is fixed (which is really bad because it means URLs to the per-node links to the manual will go bad). That said, I think it is prudent to document *requirements* of aclocal that the user of aclocal and authors of macro files must meet. But document them that way, and do it only if they can't be fixed. I'm still not totally sure why aclocal didn't try to use traces, but one reason I can think of is the following: macros from unrelated third-party packages may otherwise interfere with each other; but also, macros from different versions of the same third-party package might all be found in the aclocal search path. Can we please check history here before committing to anything? I cannot tell without experimenting (e.g., installing lots of *-dev distro packages on my box) whether this is a problem now, or would be a problem when tracing with the Autoconf-without-aclocal language (which is defined by Autoconf already) or with Gary's proposed new language. A problem to take into account is that if aclocal fails due to macro interaction for some user, she might not be able to do anything about it (because she is not root) thus making the whole installation a bit unusable. Thanks, Ralf Document in detail some limitations of aclocal. * doc/automake.texi (Limitations of aclocal): New section. * tests/aclocal-limit-defun.test: New test, checking that the aclocal limitation(s) exposed in the newly added manual section does really hold. * tests/aclocal-limit-include.test: Likewise. * tests/Makefile.am (TESTS): Updated. * .gitignore: Updated. * THANKS: Updated. From a report by Nick Bowler.
Re: tests updates
* Stefano Lattarini wrote on Wed, Nov 03, 2010 at 02:27:47PM CET: On Monday 01 November 2010, Ralf Wildenhues wrote: I'm so totally behind on patches and not getting better, that the strategy of ignoring testsuite work will not help either. So how about the following. IIRC you suggested a branch for low-danger testsuite updates. I'm not sure if a single branch would always be the right thing to do, often things that are independent can better be treated in independent branches. But anyway, how about if you go ahead with the idea of merging such patches, preferably based off of maint and merge to master (unless there are really good reasons why branch-1.11 would need them too), with the following strategy similar to Libtool: you post the patches, and push them after 72 hours if no feedback by then. WDYT? Does that sound good enough for you? Definitely yes, thanks! Good. I wouldn't want to lose your work just over my lack of time. Just one question: what about the already-existing tests-init branch? Should I try to bring it to a point where it can be easily merged into master, and then forget about it, or should it continue to live parallel to master? Right now the branch looks like its changes would be fairly safe to merge to master, but also, it would mean that sharing testsuite patches between branch-1.11 and master may become a bit more cumbersome. So I'd say it depends a bit on where you want to go with this in the long run. We can easily move to a strategy of having new testsuite stuff added to master only by default, and only care about branch-1.11 for fixing existing regressions and serious bugs, which would probably make the situation easier. Of course there are other active branches too, that shouldn't have a harder-than-necessary time. We could treat merges similarly to patches in announcing the intention to merge 72h before the fact, in those cases where there is doubt over the merge (or the precise point at which a merge should be done). I must admit that I don't have all that much experience with merges of longer-term branches done by more than one person; one alternative would be that you suggest the merge and I do it (if that works out). Testing such merges usually requires a bit of additional work, in that both branches need to be checked for global changes that need adjusting in the respective other branch. Let's see how this works out. Cheers, Ralf
Re: [PATCH v2] Overhauled and modularized tests in `instspc.test'.
Hi Stefano, * Stefano Lattarini wrote on Wed, Nov 03, 2010 at 03:10:30PM CET: On Friday 24 September 2010, Stefano Lattarini wrote: Now that I've run all those tests (whose results are posted in this thread), ok to push to master? Pinging the patch again, following this: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg3.html Note that this patch is based off of master, not of maint, for reasons stated here: http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00180.html OK to push? Hmm, I didn't have this one on my radar any more. I think that's because in: http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00172.html I OKed the patch with nits addressed. There was some more discussion about things after that, but AFAICS you did not post a new full patch. If you'd like me to take another look, please post the patch as you intend to push it. Also, in above message I suggested an optimization of your patch; please indicate whether you intend to work on it. Thanks, Ralf
Re: Force a file to be compiled always
Hi Benjamin, * Benjamin Bihler wrote on Wed, Nov 03, 2010 at 11:00:35AM CET: almost ten years ago there was a question in this mailing list how to force a source file to be compiled always. http://lists.gnu.org/archive/html/automake/2002-02/msg00099.html Unfortunately the solutions mentioned there seem not to work with me. My Makefile.am looks like this: --- lib_LTLIBRARIES = libMyLibrary.la libMyLibrary_la_SOURCES = MySourceFile.cpp \ MySourceFile.h --- and when I add the .PHONY-line I get this Makefile.am: --- lib_LTLIBRARIES = libMyLibrary.la .PHONY : MySourceFile.cpp libMyLibrary_la_SOURCES = MySourceFile.cpp \ MySourceFile.h --- I think for it to work you'd need something like: lib_LTLIBRARIES = libMyLibrary.la .PHONY : $(srcdir)/MySourceFile.cpp libMyLibrary_la_SOURCES = $(srcdir)/MySourceFile.cpp \ MySourceFile.h An alternative and more portable (to some non-GNU makes) way than marking targets as phony is letting them depend upon some non-existing pseudo target. It is comonly named FORCE, and you need to ensure no file with that name exists in the source or the build tree: lib_LTLIBRARIES = libMyLibrary.la MySourceFile.cpp: FORCE FORCE: libMyLibrary_la_SOURCES = MySourceFile.cpp \ MySourceFile.h An even better alternative however is to not lie to make about the actual dependency structure: why do you need your file to be compiled always? The answer to that question specifies what the file really should depend upon (e.g., upon Makefile?). Hope that helps. Cheers, Ralf
bug#7321: dejagnu support should provide for recheck target
Severity: wishlist The recheck feature is useful on a broader scale. recheck should be renamed to recheck-TESTS, and the recheck target depend on that. There should be a recheck-DEJAGNU (also depended on by recheck if dejagnu is used) that implements similar functionality. See here for some implementation details: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00825.html Cheers, Ralf
bug#7209: test automake bug
Let's close this test PR.
Re: Failure on test parallel-tests5.test
[ http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/5061 ] * Lluís Batlle i Rossell wrote on Sun, Oct 31, 2010 at 05:49:00PM CET: On Sun, Oct 31, 2010 at 10:48:10AM +0100, Lluís Batlle i Rossell wrote: On Sun, Oct 31, 2010 at 10:01:09AM +0100, Ralf Wildenhues wrote: (ulimit -t 300; sh -c 'while make check TESTS=parallel-tests5.test; do :; done') Which make implementation and version do you use? Which distro is this? It's NixOS. gnu make 3.82. After many retries, the test failed again. The part of the log about the failure says: .. gcc -DPACKAGE_NAME=\parallel-tests5\ -DPACKAGE_TARNAME=\parallel-tests5\ -DPACKAGE_VERSION=\1.0\ -DPACKAGE_STRING=\parallel-tests5\ 1.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\parallel-tests5\ -DVERSION=\1.0\ -I. -g -O2 -MT foo4.o -MD -MP -MF .deps/foo4.Tpo -c -o foo4.o foo4.c building foo5.o mv -f .deps/foo2.Tpo .deps/foo2.Po make[2]: vfork: Function not implemented make[2]: *** Deleting file `foo2.o' Interesting. [...] make[2]: Leaving directory `/tmp/nix-build-v732qfq81afcilibmp48al3gqw1avpvz-automake-1.11.1.drv-0/automake-1.11.1/tests/parallel-tests5.dir' make[1]: *** [check-TESTS] Error 2 make[1]: Leaving directory `/tmp/nix-build-v732qfq81afcilibmp48al3gqw1avpvz-automake-1.11.1.drv-0/automake-1.11.1/tests/parallel-tests5.dir' make: *** [check-am] Error 2 It looks like a 'make' or glibc problem, right? It looks like a NixOS or a 'make' problem. Can you report this to the NixOS developers to see if they have any input on it? Hmm, lemme see; Ludovic, are you the right person to ask on this? Thanks, Ralf
Re: User extensions
Hi Valentin,
let's move to the -patches list. And sorry for the long delay.
* Valentin David wrote on Fri, Sep 03, 2010 at 06:56:53PM CEST:
I propose a patch as attached.
* The lang_*_rewrite are added to the Language structure. The default
is lang_sub_obj. They do not return anymore the object extension
because the field 'output_extensions' already computes it.
As Stefano already suggested, this change is fine for master in a patch
by itself, and when it passes 'make check', regardless of the rest.
Please format patches in the way that is done throughout Automake
history (see HACKING), with ChangeLog entries, test suite additions,
and commit including modifications induced by ./bootstrap (given the
most recent stable Autoconf version in $PATH). Thanks. Generated files
need not be listed in the log.
* Compilers that generate source files might still generate dependency files.
* --libdir= can be called several times, the arguments can also have a
list of paths separated by a colon. Empty paths correspond to the
original libdir.
Due to the colon/semicolon issues, how about we just ignore the issue
for now and require one --libdir argument per directory?
Also, the version issues can end up fairly intricate: we cannot really
expect automake 1.13 to successfully load the same Perl modules that
were meant for 1.12; there are *lots* of things that can go wrong, and
we just opened a can of API worms. Still, I would really like to see
progress here, so let's for the moment not yet settle on a system-wide
(set of) directory(ies) where such additional third-party files should
end up at. Another issue is overriding Automake's own .am files; we've
always treated them as requiring to be in sync with the automake.in
version and it could end up being pretty tricky to specify their API as
public in any way.
Also, I like the approach of calling the whole feature experimental and
at the same time asking users to tell us which features from automake.in
they need so we can document them and add testsuite coverage for them so
we can be sure to not break them in the future.
* For all libdir, all libdir/lang/*.pm are loaded. This happens right
after parsing the options.
The test tests/user_def_lang.test should show how the feature works.
I can understand that loading perl files is not really nice because
there easily can be problems of backward compatibility.
Exactly.
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. The new code should have a NEWS
entry and at least some documentation in the manual. You can target
a new branch that is meant for eventual inclusion into master, let's
name it user-ext, and whether you base patches off of maint or of master
I don't care. The latter might be easier for you.
Some nits below, in addition (or in contrast ;-) to Stefano's.
--- a/automake.in
+++ b/automake.in
@@ -1858,17 +1871,15 @@ sub handle_single_transform ($%)
}
}
- # Note: computed subr call. The language rewrite function
- # should return one of the LANG_* constants. It could
- # also return a list whose first value is such a constant
- # and whose second value is a new source extension which
- # should be applied. This means this particular language
- # generates another source file which we must then process
- # further.
- my $subr = \{'lang_' . $lang-name . '_rewrite'};
- my ($r, $source_extension)
- = $subr ($directory, $base, $extension,
+ # The language rewrite function should return one of the
+# LANG_* constants.
+ my $r
+ = {$lang-rewrite} ($directory, $base, $extension,
$nonansi_obj, $have_per_exec_flags, $var);
+
+ my $output_extension
+ = ({$lang-output_extensions} ($extension))[0];
+
# Skip this entry if we were asked not to process it.
next if $r == LANG_IGNORE;
@@ -1876,9 +1887,9 @@ sub handle_single_transform ($%)
$linker = $lang-linker;
my $this_obj_ext;
- if (defined $source_extension)
+ if ($output_extension ne '.$(OBJEXT)')
Why this? This looks wrong, but I cannot judge because I don't
understand why your patch would need this.
{
- $this_obj_ext = $source_extension;
+ $this_obj_ext = $output_extension;
$derived_source = 1;
}
elsif ($lang-ansi)
@@ -2056,10 +2067,19 @@ sub handle_single_transform ($%)
$lang-target_hook ($aggregate, $object, $full, %transform);
}
+ # Transform .o or $o file into .P file (for automatic
+ # dependency code).
+ if ($lang $lang-autodep ne
Re: User extensions
* Valentin David wrote on Mon, Nov 01, 2010 at 09:41:47PM CET:
On Mon, Nov 1, 2010 at 8:18 PM, Ralf Wildenhues wrote:
Also, I like the approach of calling the whole feature experimental and
at the same time asking users to tell us which features from automake.in
they need so we can document them and add testsuite coverage for them so
we can be sure to not break them in the future.
The problem is that the important variables in automake.in are all
local (my). So even if you set the module to package Automake, you
still cannot access to them without modifying automake.in. We should
have accessors to most of them. For example, in the patch I sent,
there is a bug in the test case, as it tries to add something
%clean_files but actually does not.
Good points. Accessors sound like a good idea; more generally, it will
probably end up being cleanest to do some restructuring so that a more
stable API can be provided.
The testsuite additions should ensure that such things as cleaning files
actually work.
@@ -1876,9 +1887,9 @@ sub handle_single_transform ($%)
$linker = $lang-linker;
my $this_obj_ext;
- if (defined $source_extension)
+ if ($output_extension ne '.$(OBJEXT)')
Why this? This looks wrong, but I cannot judge because I don't
understand why your patch would need this.
lang_..._rewrite sometimes returned a pair where the rhs to be
$source_extension, which correspond to the extension of the generated
file. However, there is already another entry that does this. When I
rewrote the lang_..._rewrite, I just dropped this variable. Now it
uses $output_extension which is always defined ($source_extension was
also not really a wise name given it is the generated file, not really
a source). Then to check if it is derived source (which means needs
another compiler after), the test is to check the extension needed of
the output.
OK.
{
- $this_obj_ext = $source_extension;
+ $this_obj_ext = $output_extension;
$derived_source = 1;
}
elsif ($lang-ansi)
@@ -2056,10 +2067,19 @@ sub handle_single_transform ($%)
$lang-target_hook ($aggregate, $object, $full, %transform);
}
+ # Transform .o or $o file into .P file (for automatic
+ # dependency code).
+ if ($lang $lang-autodep ne 'no')
+ {
+ my $depfile = $object;
+ $depfile =~ s/\.([^.]*)$/.P$1/;
+ $depfile =~ s/\$\(OBJEXT\)$/o/;
+ $dep_files{dirname ($depfile) . '/$(DEPDIR)/'
+ . basename ($depfile)} = 1;
+ }
+
if ($derived_source)
{
- prog_error ($lang-name . has automatic dependency tracking)
- if $lang-autodep ne 'no';
This removal (without replacement) strikes me as weird. What did you
need it for? We should have a testsuite addition that exposes the
error, and see that a fix of yours keeps the old failure working.
It is wrong to assume that a compiler that generates source files
cannot have automatic dependencies.
Sure. What I'm not sure is whether the rest of the Automake code
doesn't provide the required functionality only for such languages.
Hmm, this was introduced in Release-1-4f-43-g081f2d5, which is really
long ago; it might still be valid but then again maybe not.
How about we remove it at the point where we add testsuite coverage for
a language that has this feature (so we can be fairly sure that Automake
is prepared)?
Take Stratego, this compiler takes
.str files and generate .c files. But several .str files can be
dependency to one .c file. And the compiler actually generate a
dependency file. The current way is now to have a -include $(wildcard
*.dep) in each file. And this is not really good thing.
See http://strategoxt.org/
Thanks for the explanations.
Secondly this error message can appear only on a bug in Automake, and
cannot be triggered from the files of the user. So you cannot really
make a test that fails here. And now that the autodep section (moved
right before) can handle derived source, this assertion is not useful
anymore.
+register_language (# Short name of the language (c, f77...).
+ 'name' = foo,
+ # Nice name of the language (C, Fortran 77...).
+ 'Name' = Foo,
+ # List of configure variables which must be defined.
+ 'config_vars' = ['FOO'],
+ 'autodep' = 'FOO',
+
+ # Name of the compiling variable (COMPILE).
+ 'compiler' = FOOCOMPILE,
+ # Content of the compiling variable.
+ 'compile' = '$(FOO) $(FOOFLAGS)',
+ # Flag to require compilation without linking (-c).
+ 'extensions' = ['.foo'],
+ # A subroutine to compute a list of possible extensions
tests updates
Hi Stefano, I'm so totally behind on patches and not getting better, that the strategy of ignoring testsuite work will not help either. So how about the following. IIRC you suggested a branch for low-danger testsuite updates. I'm not sure if a single branch would always be the right thing to do, often things that are independent can better be treated in independent branches. But anyway, how about if you go ahead with the idea of merging such patches, preferably based off of maint and merge to master (unless there are really good reasons why branch-1.11 would need them too), with the following strategy similar to Libtool: you post the patches, and push them after 72 hours if no feedback by then. WDYT? Does that sound good enough for you? For existing patches that you already posted, may I ask for one more ping including above 72 hours (and maybe not ping all of them at once ;-) Thanks, and sorry for the long delays, Ralf
More problems with `make -n' in automake-generated rules.
I noticed more issues with automake-generated rules and `make -n':
1) The solutions documented in the `Multiple Outputs' node are not safe
for use with `make -n'.
2) Consequently, the lisp rules are broken, but also the Yacc, Vala, and
config.h rules in some cases.
3) The rules to update Makefile, but also those to update and
Makefile.in, are broken in some circumstances, too.
The patch below fixes the documentation and addresses (2). The patch
doesn't add testsuite coverage for Vala because there are several
changes pending for this; I'm guessing the code will work differently
afterwards anyway.
I'm not sure how useful it is to fix (3). It is not easy as a user to
get GNU make to not update any of the dependencies of the Makefile file,
thanks to its remaking feature (info make Remaking Makefiles). I'll
reply with a patch for the 'Makefile' rule, but in order to expose that
bug, you need to use something like this in a subdirectory of a package:
make -n Makefile AM_MAKEFLAGS=-n Makefile
I don't think users go to this extent just to have `make -n' work, and
they definitely won't get the above right on the first try; but then the
rebuild will already have kicked in, making the issue moot for the
second try.
Before applying this (to maint, probably) I would appreciate if someone
could look over it to make sure the patch looks sane. Thanks.
Thanks,
Ralf
Fix and document rules to not touch the tree with `make -n'.
* doc/automake.texi (Multiple Outputs): Document the problem of
modifications during dry-run execution, propose solution.
* NEWS: Update.
* automake.in (lang_vala_finish_target): Split recipe so the
stamp file is not removed with GNU `make -n'.
(lang_yacc_target_hook): Separate removal of parser output file
and header remaking.
* lib/am/lisp.am ($(am__ELCFILES)): Determine whether -n was
passed to make, take care not to remove any files in that case.
* lib/am/remake-hdr.am (%CONFIG_H%): Separate removal of
%STAMP% file from induced remaking of config header.
* tests/autohdrdry.test, tests/lispdry.test, tests/yaccdry.test:
New tests.
* tests/Makefile.am (TESTS): Update.
diff --git a/NEWS b/NEWS
index 64afd8c..7ce106a 100644
--- a/NEWS
+++ b/NEWS
@@ -99,6 +99,10 @@ Bugs fixed in 1.11a:
- The order of Yacc and Lex flags is fixed to be consistent with other
languages: $(AM_YFLAGS) comes before $(YFLAGS), and $(AM_LFLAGS) before
$(LFLAGS), so that the user variables override the developer variables.
+
+ - Rules generated by Automake now try harder to not change any files when
+`make -n' is invoked. Fixes include compilation of Emacs Lisp, Vala, or
+Yacc source files and the rule to update config.h.
New in 1.11:
diff --git a/automake.in b/automake.in
index cb5fe24..42eff2b 100644
--- a/automake.in
+++ b/automake.in
@@ -6050,11 +6050,11 @@ sub lang_vala_finish_target ($$)
{
foreach my $file ($var-value_as_list_recursive)
{
- $output_rules .= \$(srcdir)/$file:
\$(srcdir)/${derived}_vala.stamp\n.
-\...@if test -f \$@; then :; else \\\n.
-\t rm -f \$(srcdir)/${derived}_vala.stamp; \\\n.
-\t \$(am__cd) \$(srcdir) \$(MAKE) \$(AM_MAKEFLAGS)
${derived}_vala.stamp; \\\n.
-\tfi\n
+ $output_rules .= \$(srcdir)/$file:
\$(srcdir)/${derived}_vala.stamp\n
+. \...@if test -f \$@; then :; else rm -f
\$(srcdir)/${derived}_vala.stamp; fi\n
+. \...@if test -f \$@; then :; else \\\n
+. \t \$(am__cd) \$(srcdir) \$(MAKE) \$(AM_MAKEFLAGS)
${derived}_vala.stamp; \\\n
+ . \tfi\n
if $file =~ s/(.*)\.vala$/$1.c/;
}
}
@@ -6070,11 +6070,11 @@ sub lang_vala_finish_target ($$)
'--vapi', '--internal-vapi', '--gir')))
{
my $headerfile = $flag;
- $output_rules .= \$(srcdir)/$headerfile:
\$(srcdir)/${derived}_vala.stamp\n.
- \...@if test -f \$@; then :; else \\\n.
- \t rm -f \$(srcdir)/${derived}_vala.stamp; \\\n.
- \t \$(am__cd) \$(srcdir) \$(MAKE) \$(AM_MAKEFLAGS)
${derived}_vala.stamp; \\\n.
- \tfi\n;
+ $output_rules .= \$(srcdir)/$headerfile:
\$(srcdir)/${derived}_vala.stamp\n
+ . \...@if test -f \$@; then :; else rm -f
\$(srcdir)/${derived}_vala.stamp; \n
+ . \...@if test -f \$@; then :; else \\\n
+ . \t \$(am__cd) \$(srcdir) \$(MAKE) \$(AM_MAKEFLAGS)
${derived}_vala.stamp; \\\n
+ . \tfi\n;
# valac is not used when building from dist tarballs
# distribute the generated files
@@ -6169,10 +6169,8 @@ sub lang_yacc_target_hook
$output_rules .=
$condstr${header}: $output\n
# Recover from removal of $header
- . $condstr...@if test ! -f \$@; then \\\n
- . $condstr\t rm -f
Re: More problems with `make -n' in automake-generated rules.
* Ralf Wildenhues wrote on Mon, Nov 01, 2010 at 10:18:55PM CET: 3) The rules to update Makefile, but also those to update and Makefile.in, are broken in some circumstances, too. [...] I'm not sure how useful it is to fix (3). It is not easy as a user to get GNU make to not update any of the dependencies of the Makefile file, thanks to its remaking feature (info make Remaking Makefiles). I'll reply with a patch for the 'Makefile' rule, but in order to expose that bug, you need to use something like this in a subdirectory of a package: make -n Makefile AM_MAKEFLAGS=-n Makefile I don't think users go to this extent just to have `make -n' work, and they definitely won't get the above right on the first try; but then the rebuild will already have kicked in, making the issue moot for the second try. Here it is. Cheers, Ralf Fix GNU `make -n Makefile' in subdirs to not touch the tree. * lib/am/configure.am (%MAKEFILE%): Split rule in nonrecursive and possibly-recursive parts, for GNU `make -n'. * tests/remakedry.test: New test. * tests/Makefile.am (TESTS): Update. * NEWS: Update. diff --git a/NEWS b/NEWS index 6bc0d6f..76e6543 100644 --- a/NEWS +++ b/NEWS @@ -48,7 +48,7 @@ Bugs fixed in 1.11.0a: - Rules generated by Automake now try harder to not change any files when `make -n' is invoked. Fixes include compilation of Emacs Lisp, Vala, or -Yacc source files and the rule to update config.h. +Yacc source files and the rules to update config.h and a subdir Makefile. New in 1.11: diff --git a/lib/am/configure.am b/lib/am/configure.am index e9299d6..c10b377 100644 --- a/lib/am/configure.am +++ b/lib/am/configure.am @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009 Free +## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010 Free ## Software Foundation, Inc. ## This program is free software; you can redistribute it and/or modify @@ -75,12 +75,16 @@ endif %?TOPDIR_P% ?TOPDIR_P? echo ' $(SHELL) ./config.status'; \ ?TOPDIR_P? $(SHELL) ./config.status;; \ ?!TOPDIR_P?cd $(top_builddir) $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \ + esac +## Split the nonrecursive part off, so GNU `make -n' will not execute it. + @case '$?' in \ + *config.status*) ;;\ *) \ ## FIXME: $(am__depfiles_maybe) lets us re-run the rule to create the ## .P files. Ideally we wouldn't have to do this by hand. echo ' cd $(top_builddir) $(SHELL) ./config.status %CONFIG-MAKEFILE% $(am__depfiles_maybe)'; \ cd $(top_builddir) $(SHELL) ./config.status %CONFIG-MAKEFILE% $(am__depfiles_maybe);; \ - esac; + esac DIST_COMMON += %MAKEFILE-AM% diff --git a/tests/Makefile.am b/tests/Makefile.am index 9c81564..a9aca1e 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -619,6 +619,7 @@ remake4.test \ remake5.test \ remake6.test \ remake7.test \ +remakedry.test \ regex.test \ req.test \ reqd.test \ diff --git a/tests/remakedry.test b/tests/remakedry.test new file mode 100755 index 000..dab46f3 --- /dev/null +++ b/tests/remakedry.test @@ -0,0 +1,82 @@ +#! /bin/sh +# Copyright (C) 2010 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +# Make sure GNU `make -n' doesn't trigger file updates when Makefile +# is out of date. + +# The subdir rebuilding rules rely on GNU make automatically updating +# the makefile and its prerequisites (through am--refresh). +required=GNUmake +. ./defs || Exit 1 + +set -e + +cat configure.in 'END' +AC_CONFIG_FILES([sub/Makefile]) +AC_OUTPUT +END + +cat Makefile.am 'END' +SUBDIRS = sub +END +mkdir sub +: sub/Makefile.am + +$ACLOCAL +$AUTOMAKE +$AUTOCONF +./configure +$MAKE + +# The toplevel rule is not problematic, as it is not recursive. +$sleep +touch Makefile.in +$sleep +$MAKE -n Makefile +test `ls -1t Makefile Makefile.in | sed 1q` = Makefile.in +$MAKE Makefile +test `ls -1t Makefile Makefile.in | sed 1q` = Makefile + +$sleep +touch config.status +$sleep +$MAKE -n Makefile +test `ls -1t Makefile config.status | sed 1q` = config.status +$MAKE Makefile +test `ls -1t Makefile config.status | sed 1q` = Makefile + +# The subdir rules are fixed by separating the recursive part from the rest. +cd sub +$sleep +touch Makefile.in +$sleep +$MAKE -n
Fix install-strip when $(STRIP) contains several words.
I was wondering whether, if $(STRIP) is empty, one would want
install-strip to have the same effect as install, but then again,
the value of $(STRIP) at 'make install' time isn't currently used
for all stripping anyway: libtool figures out how to strip things
at configure time (and sets things differently for static and shared
libraries). Thus, I have kept the semantics of still passing the -s
flag to install-sh even if STRIP is empty.
While here, I've updated the comment about double quotes after tracing
it back to when it was added to automake.in.
AFAIK there is no reliable portable way to find out whether some file
has been stripped or not (for the testsuite).
This is for maint. I'll leave a couple of days for comments before
pushing.
Thanks,
Ralf
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.
diff --git a/lib/am/install.am b/lib/am/install.am
index d261070..01ae49a 100644
--- a/lib/am/install.am
+++ b/lib/am/install.am
@@ -1,5 +1,5 @@
## automake - create Makefile.in from Makefile.am
-## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008, 2009 Free Software
+## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008, 2009, 2010 Free Software
## Foundation, Inc.
## This program is free software; you can redistribute it and/or modify
@@ -90,9 +90,17 @@ install-strip:
## It's OK to override both with INSTALL_STRIP_PROGRAM, because
## INSTALL_STRIP_PROGRAM uses install-sh (see m4/strip.m4 for a rationale).
##
-## Use double quotes here because we might need to interpolate some
-## backquotes at runtime.
- $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM=$(INSTALL_STRIP_PROGRAM) \
- install_sh_PROGRAM=$(INSTALL_STRIP_PROGRAM) INSTALL_STRIP_FLAG=-s \
- `test -z '$(STRIP)' || \
- echo INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'` install
+## Use double quotes for the *_PROGRAM settings because we might need to
+## interpolate some backquotes at runtime.
+##
+## The case for empty $(STRIP) is separate so that it is quoted correctly for
+## multiple words, but does not expand to an empty words if STRIP is empty.
+ if test -z '$(STRIP)'; then \
+ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM=$(INSTALL_STRIP_PROGRAM) \
+ install_sh_PROGRAM=$(INSTALL_STRIP_PROGRAM) INSTALL_STRIP_FLAG=-s
\
+ install; \
+ else \
+ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM=$(INSTALL_STRIP_PROGRAM) \
+ install_sh_PROGRAM=$(INSTALL_STRIP_PROGRAM) INSTALL_STRIP_FLAG=-s
\
+ INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)' install; \
+ fi
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 6673293..0b85159 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -696,6 +696,8 @@ stamph2.test \
stdlib.test \
stdlib2.test \
strip.test \
+strip2.test \
+strip3.test \
subdir.test \
subdir2.test \
subdir3.test \
diff --git a/tests/strip2.test b/tests/strip2.test
new file mode 100755
index 000..5786ded
--- /dev/null
+++ b/tests/strip2.test
@@ -0,0 +1,54 @@
+#! /bin/sh
+# Copyright (C) 2010 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+# Ensure install-strip works when STRIP consists of more than one word.
+# This test needs GNU binutils strip. See sister test strip3.
+
+required=strip
+. ./defs || Exit 1
+
+set -e
+
+cat configure.in 'END'
+AC_PROG_CC
+AC_PROG_RANLIB
+AC_OUTPUT
+END
+
+cat Makefile.am 'END'
+bin_PROGRAMS = foo
+lib_LIBRARIES = libfoo.a
+END
+
+cat foo.c 'END'
+int main () { return 0; }
+END
+
+cat libfoo.c 'END'
+int foo () { return 0; }
+END
+
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE -a
+
+prefix=`pwd`/inst
+./configure --prefix=$prefix STRIP='strip --verbose'
+$MAKE
+$MAKE install-strip
+
+:
diff --git a/tests/strip3.test b/tests/strip3.test
new file mode 100755
index 000..b159673
--- /dev/null
+++ b/tests/strip3.test
@@ -0,0 +1,54 @@
+#! /bin/sh
+# Copyright (C) 2010 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+#
Re: [coreutils] debbugs
Hello Glen, all, and sorry for the long delay,
* Glenn Morris wrote on Thu, Oct 14, 2010 at 01:54:45AM CEST:
Ralf Wildenhues wrote (on Wed, 13 Oct 2010 at 22:46 +0200):
There is one question I haven't seen addressed yet, that I think should
be documented: is it possible to easily export the bug database to some
other format? Are there maybe any converters that do this already?
(I'm thinking that it should be possible, but if one has to completely
invent it anew, that would at least be some work.)
Hmm. I don't know - there might be some Debian tools to do that?
The bugs can be retrieved as mbox folders via the web-interface, eg:
http://debbugs.gnu.org/cgi/bugreport.cgi?mboxmaint=yes;mbox=yes;bug=7209
Internally, they are all stored as basically mbox mail folders with
some extra sections inbetween the messages. There are two extra files
that summarize the status. Everything is plain text.
Let's ignore all of this, I don't think it warrants delaying the switch.
I think we want this. Does bug-coreutils operate in Exclusive mode?
Yes, it does. By the way, that is just a term I made up. :)
Fine with me.
I think that is what would be easiest for bug-automake as well.
I agree.
OK then.
You can use my email address as maintainer and debbugs-submit moderator
for now.
Done. automake exists as a package now, and I filed a test bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7209
You should get a mail about it. You can play around with replying,
setting severity, closing, etc.
That's all good. Thanks.
When you are ready to go ahead, the final steps would be to:
1) Change the automake maintainer to bug-automake
2) Activate a router rule for bug-automake, that would redirect
messages to debbugs.gnu.org. This should happen automatically once I
add an entry to the appropriate config file on debbugs.gnu.org (has not
been tested yet, but should work).
Please do that. Thanks!
My current plan is to apply the patch below to the tree, create the HTML
page from it and upload it to
http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html
(where it will appear for the next release anyway), so you could use
that as Specific help link on http://debbugs.gnu.org/.
+...@uref{http://debbugs.gnu.org/@/cgi/@/pkgreport.cgi?package=automake;max-bugs=100;base-order=1;bug-rev=1,
+bug tracker}.
May be better to simply use http://debbugs.gnu.org/automake there.
Good idea. I've uploaded the fixed text to above URL now, will push the
commit soon.
Thanks,
Ralf
Re: using autoconf with ppuxlc++,spuxlc++
* John Wohlbier wrote on Wed, Oct 27, 2010 at 06:08:47PM CEST:
On Wed, Oct 27, 2010 at 12:24 AM, Ralf Wildenhues wrote:
How exactly do you invoke configure, what does configure output as
dependency mechanism for these two compilers, where are the manpages
for the compilers?
1) I'm not exactly sure what you're asking about invoking configure. We have
3 configure.acs, and the first one uses AC_CONFIG_SUBDIRS to run the
configures for the PPE and SPE. Those configures are done as cross compiles
using configure.gnu. I can give you more detail about this if it's needed.
3) I've attached the output of ppuxlc++ manpage. Let me know if you need
anything else from this.
2) I think you've found the thread to pull on. I see this:
checking dependency style of ppuxlc... (cached) gcc3
The fact that it's cached makes me nervous, b/c if I scan up the output I
find the dependency style listed a couple times.
checking dependency style of gcc... gcc3
checking dependency style of g++... gcc3
If I'm guessing correctly then the last lines happen during toplevel
configure, and the ppuxlc checking one in a sub configure? If yes, then
you need to ensure to unset the respective cache variable before the
later checks (am_cv_{CC,CXX}_dependencies_compiler_type). If no, you
need to ensure $CC/$CXX are set to the right compilers before
AC_PROG_{CC,CXX}.
It seems like it's possible that the boiler plate kind of checks
(including dependency style) are being made with gcc/g++ before I'm able to
change to the cross compiler and it's using the previously cached value.
Yep, that's one of the possibilities.
Either that, or depcomp really does think ppuxlc++ has gcc3 dependency
style.
Unlikely.
Here's a few lines from my configure.ac where CCS_WITH_PPU_COMPILER,
CCS_TUNE_PCC, CCS_TUNE_PCXX are macros that set CC and CXX to be ppuxlc and
ppuxlc++ respectively (I didn't originally write those macros, but I think
they were written since AC_PROG_CC and AC_PROG_CXX don't support these
compilers). With this ordering, should those boiler plate checks be
performed with the ppuxlc(++)? Is there a way I can specifically call
checking dependency style?
No. Can you share the CCS_* macros though (including other non-public
macros they require or invoke)? From what you posted I cannot tell what
is happening.
AC_INIT
AC_CONFIG_AUX_DIR(config)
AM_INIT_AUTOMAKE
AC_PROG_LIBTOOL
AC_PROG_LN_S
AC_DISABLE_SHARED
CCS_WITH_PPU_COMPILER
CCS_TUNE_PCC
CCS_TUNE_PCXX
Cheers,
Ralf
Re: User extensions
Hi Valentin,
let's move to the -patches list. And sorry for the long delay.
* Valentin David wrote on Fri, Sep 03, 2010 at 06:56:53PM CEST:
I propose a patch as attached.
* The lang_*_rewrite are added to the Language structure. The default
is lang_sub_obj. They do not return anymore the object extension
because the field 'output_extensions' already computes it.
As Stefano already suggested, this change is fine for master in a patch
by itself, and when it passes 'make check', regardless of the rest.
Please format patches in the way that is done throughout Automake
history (see HACKING), with ChangeLog entries, test suite additions,
and commit including modifications induced by ./bootstrap (given the
most recent stable Autoconf version in $PATH). Thanks. Generated files
need not be listed in the log.
* Compilers that generate source files might still generate dependency files.
* --libdir= can be called several times, the arguments can also have a
list of paths separated by a colon. Empty paths correspond to the
original libdir.
Due to the colon/semicolon issues, how about we just ignore the issue
for now and require one --libdir argument per directory?
Also, the version issues can end up fairly intricate: we cannot really
expect automake 1.13 to successfully load the same Perl modules that
were meant for 1.12; there are *lots* of things that can go wrong, and
we just opened a can of API worms. Still, I would really like to see
progress here, so let's for the moment not yet settle on a system-wide
(set of) directory(ies) where such additional third-party files should
end up at. Another issue is overriding Automake's own .am files; we've
always treated them as requiring to be in sync with the automake.in
version and it could end up being pretty tricky to specify their API as
public in any way.
Also, I like the approach of calling the whole feature experimental and
at the same time asking users to tell us which features from automake.in
they need so we can document them and add testsuite coverage for them so
we can be sure to not break them in the future.
* For all libdir, all libdir/lang/*.pm are loaded. This happens right
after parsing the options.
The test tests/user_def_lang.test should show how the feature works.
I can understand that loading perl files is not really nice because
there easily can be problems of backward compatibility.
Exactly.
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. The new code should have a NEWS
entry and at least some documentation in the manual. You can target
a new branch that is meant for eventual inclusion into master, let's
name it user-ext, and whether you base patches off of maint or of master
I don't care. The latter might be easier for you.
Some nits below, in addition (or in contrast ;-) to Stefano's.
--- a/automake.in
+++ b/automake.in
@@ -1858,17 +1871,15 @@ sub handle_single_transform ($%)
}
}
- # Note: computed subr call. The language rewrite function
- # should return one of the LANG_* constants. It could
- # also return a list whose first value is such a constant
- # and whose second value is a new source extension which
- # should be applied. This means this particular language
- # generates another source file which we must then process
- # further.
- my $subr = \{'lang_' . $lang-name . '_rewrite'};
- my ($r, $source_extension)
- = $subr ($directory, $base, $extension,
+ # The language rewrite function should return one of the
+# LANG_* constants.
+ my $r
+ = {$lang-rewrite} ($directory, $base, $extension,
$nonansi_obj, $have_per_exec_flags, $var);
+
+ my $output_extension
+ = ({$lang-output_extensions} ($extension))[0];
+
# Skip this entry if we were asked not to process it.
next if $r == LANG_IGNORE;
@@ -1876,9 +1887,9 @@ sub handle_single_transform ($%)
$linker = $lang-linker;
my $this_obj_ext;
- if (defined $source_extension)
+ if ($output_extension ne '.$(OBJEXT)')
Why this? This looks wrong, but I cannot judge because I don't
understand why your patch would need this.
{
- $this_obj_ext = $source_extension;
+ $this_obj_ext = $output_extension;
$derived_source = 1;
}
elsif ($lang-ansi)
@@ -2056,10 +2067,19 @@ sub handle_single_transform ($%)
$lang-target_hook ($aggregate, $object, $full, %transform);
}
+ # Transform .o or $o file into .P file (for automatic
+ # dependency code).
+ if ($lang $lang-autodep ne
Re: User extensions
* Pippijn van Steenhoven wrote on Mon, Nov 01, 2010 at 12:43:57PM CET: On Wed, Oct 27, 2010 at 02:13:00PM +0200, Valentin David wrote: On Sat, Oct 23, 2010 at 5:27 PM, Ralf Wildenhues wrote: I haven't looked at the patch in detail yet, but will, now that the assignment papers are done (thanks!). It is done. Does this mean the feature will soon be in git? Let's see; it would be nice indeed. Ralf
Re: PATCH RFA: Add Go support
Hello Ian, let's move this part of the discussion to the automake@ list. And sorry for delays, I cannot help that ATM. * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 09:58:49PM CEST: Ralf Wildenhues writes: * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST: Ralf Wildenhues writes: Do you have, or are working on, an Automake patch for Go support? I do not have an automake patch, although that is a logical next step. I've been using libtool with a Makefile.am which uses this definition: LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \ $(AM_GOFLAGS) $(GOFLAGS) and then runs $(LTGOCOMPILE) as needed. Adding Go support to automake may be a little tricky as Go requires a slightly different compilation model: you must pass all files that are in the same package to the compiler at once. You can't compile them separately. That is not a big problem per se. However, how would you implement build parallelism? Inside gccgo? Should it eventually have jobserver support, received from make? Note that when I say a package I don't mean an entire program. A package in Go is like a single library, or what some languages call a module. E.g., the standard Go library has a fmt package, an os package, a math package, etc. When compiling Go, you must pass all files in a package to the compiler at the same time. In principle part of the compilation of a single package could be parallelized, but not in any simple or straightforward way. You can group many different Go packages together into a single .a or .so file. OK. So IIUC one example dependency graph would be something like this: ( sin.go cos.go exp.go ) - math.OBJEXT - libfem.so ( grid.go solver.go )- sub/pdesolve.OBJEXT ---^ where the sets of .go files are distinct, the sets of object files (packages) cannot be derived from their inputs (neither their names nor their contents?) but rather specified only in the makefile, and objects are subsumed in (static or shared) libraries or in programs as usual. OBJEXT may be o or obj (for w32) or lo (for libtool). We need a bit of new notation for this, and we need to teach automake about languages that shouldn't have renamed objects even in the presence of per-object flags. With libtool, naming wouldn't sound so hard, one could just go with something like: lib_LTLIBRARIES = libfem.la libfem_la_LIBADD = math.lo sub/pdesolve.lo # yes, _LIBADD math_lo_SOURCES = sin.go cos.go exp.go sub_pdesolve_lo_SOURCES = grid.go solver.go Without libtool, we could canonify $(OBJEXT) as _o: bin_PROGRAMS = fem fem_LDADD = math.$(OBJEXT) sub/pdesolve.$(OBJEXT) math_o_SOURCES = sin.go cos.go exp.go sub_pdesolve_o_SOURCES = grid.go solver.go but that looks fairly ugly to me already. Better ideas? I'm sure users will ask to generalize the scheme for other languages, where Automake operates differently now. I'm not yet sure whether that is a reason to worry or a good thing. ;-) What if files reside in subdirs (of the current directory, or of $srcdir), will objects be created in subdirs or in the current directory (and how would we avoid creation of files below $srcdir in a VPATH build, given that $srcdir is a concept not known to the compiler a priori)? Or maybe it has no objects at all? Only one object file is created for each package. It can go wherever. Should a package be an installable entity? At that point we should think about using a separate new _PRIMARY for it. Can the user split up large projects into multiple pieces, either by separate Makefile.am files for separate directories, or somehow separately compiling the set of sources in one directory, maybe by library or by program compiled? Sure. If the latter is to be supported, then things like overlapping sources become a problem (i.e., both libfoo and libbar use baz.o). That can not happen, because baz.go can only be in one package. Setups like the following are not possible in theory? if WANT_FEATURE_IN_FOO foo_lo_SOURCES += baz.go else if WANT_FEATURE_IN_BAR bar_lo_SOURCES += baz.go endif endif Thanks, Ralf
Re: PATCH RFA: Add Go support
[ dropping libtool@ ] * Ian Lance Taylor wrote on Mon, Nov 01, 2010 at 09:48:03PM CET: Ralf Wildenhues ralf.wildenh...@gmx.de writes: We need a bit of new notation for this, and we need to teach automake about languages that shouldn't have renamed objects even in the presence of per-object flags. Hmmm, no, the objects can be renamed. The agreement between source level package name and file level package name is by convention only. Misunderstanding; sorry. What I meant was that automake shouldn't by itself rename object file names. It currently does that for example with setups like foo_SOURCES = foo.c bar_SOURCES = foo.c bar_CPPFLAGS = -Dbar What if files reside in subdirs (of the current directory, or of $srcdir), will objects be created in subdirs or in the current directory (and how would we avoid creation of files below $srcdir in a VPATH build, given that $srcdir is a concept not known to the compiler a priori)? Or maybe it has no objects at all? Only one object file is created for each package. It can go wherever. Should a package be an installable entity? At that point we should think about using a separate new _PRIMARY for it. A package can be installable by itself, sure. Would that then be in the form of an object, or would you make an archive out of it? Can the user split up large projects into multiple pieces, either by separate Makefile.am files for separate directories, or somehow separately compiling the set of sources in one directory, maybe by library or by program compiled? Sure. If the latter is to be supported, then things like overlapping sources become a problem (i.e., both libfoo and libbar use baz.o). That can not happen, because baz.go can only be in one package. Setups like the following are not possible in theory? if WANT_FEATURE_IN_FOO foo_lo_SOURCES += baz.go else if WANT_FEATURE_IN_BAR bar_lo_SOURCES += baz.go endif endif Right, that is not possible, unless foo.lo and bar.lo define the same package, which would be very odd. Why? With system-dependent differences that doesn't seem too remote (the conditionals don't both have to be true on the same system). Generally, Automake users will eventually come up with some use case even for pretty remote cases ... Cheers, Ralf
Re: [coreutils] debbugs
Hello Glen, all, and sorry for the long delay,
* Glenn Morris wrote on Thu, Oct 14, 2010 at 01:54:45AM CEST:
Ralf Wildenhues wrote (on Wed, 13 Oct 2010 at 22:46 +0200):
There is one question I haven't seen addressed yet, that I think should
be documented: is it possible to easily export the bug database to some
other format? Are there maybe any converters that do this already?
(I'm thinking that it should be possible, but if one has to completely
invent it anew, that would at least be some work.)
Hmm. I don't know - there might be some Debian tools to do that?
The bugs can be retrieved as mbox folders via the web-interface, eg:
http://debbugs.gnu.org/cgi/bugreport.cgi?mboxmaint=yes;mbox=yes;bug=7209
Internally, they are all stored as basically mbox mail folders with
some extra sections inbetween the messages. There are two extra files
that summarize the status. Everything is plain text.
Let's ignore all of this, I don't think it warrants delaying the switch.
I think we want this. Does bug-coreutils operate in Exclusive mode?
Yes, it does. By the way, that is just a term I made up. :)
Fine with me.
I think that is what would be easiest for bug-automake as well.
I agree.
OK then.
You can use my email address as maintainer and debbugs-submit moderator
for now.
Done. automake exists as a package now, and I filed a test bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7209
You should get a mail about it. You can play around with replying,
setting severity, closing, etc.
That's all good. Thanks.
When you are ready to go ahead, the final steps would be to:
1) Change the automake maintainer to bug-automake
2) Activate a router rule for bug-automake, that would redirect
messages to debbugs.gnu.org. This should happen automatically once I
add an entry to the appropriate config file on debbugs.gnu.org (has not
been tested yet, but should work).
Please do that. Thanks!
My current plan is to apply the patch below to the tree, create the HTML
page from it and upload it to
http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html
(where it will appear for the next release anyway), so you could use
that as Specific help link on http://debbugs.gnu.org/.
+...@uref{http://debbugs.gnu.org/@/cgi/@/pkgreport.cgi?package=automake;max-bugs=100;base-order=1;bug-rev=1,
+bug tracker}.
May be better to simply use http://debbugs.gnu.org/automake there.
Good idea. I've uploaded the fixed text to above URL now, will push the
commit soon.
Thanks,
Ralf
heads-up: bug-automake will be bug-tracked
Hello Automake bug reporters, and sorry for the cross post, starting pretty soon, the bug-automake mailing list will be used to drive the GNU Bug Tracker for Automake, http://debbugs.gnu.org/automake so new messages to this list will automatically open new bug reports and replies to existing threads will be added to existing bug reports. Bug reporting instructions have been updated at http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html Thanks for your attention and your interest in GNU Automake, Ralf
Re: Copy files in VPATH build
* Paul J. Davis wrote on Sun, Oct 31, 2010 at 12:10:01AM CEST: On Oct 30, 2010, at 5:17 PM, Jason Curl jcurln...@arcor.de wrote: When building my package with ./configure everything works well as some datafiles that are required for tests are in the correct place (my tests don't need to be installed with make install). However, when I use VPATH builds with ../configure, I don't know how to get my data files copied from the source to the current build path. I've just read up on VPATH, and I think gmake is assuming, that while the datafiles are in the source, the dependencies are satisfied, even though they aren't in the build directory. The following rules don't work: Right. If @srcdir@ is '.', then GNU make will error out here (non-GNU make would destroy your data, except that it will barf over the use of $ outside of inference rules first). test.ini: @srcdir@/test.ini cp $ $@ ./test.ini: @srcdir@/test.ini cp $ $@ But the rule: test2.ini: @srcdir@/test.ini cp $ $@ does work, but I don't need to rename the file in the copy, and when not using VPATH, it just performs a useless copy. Correct as well. The only thing I've way I've overcome this is to have a test runner that gets built by configure so it can have access to both the build and source directory paths. Good idea. An alternative can be to use AC_CONFIG_LINKS with identical source and target name for files: the link-or-copy will the only be made if in a VPATH build. You need Autoconf = 2.62 and Automake = 1.11 for this to work correctly (please set AC_PREREQ and Automake Option to this end, because the older versions had bugs that could cause source file removal.) Please report any remaining bugs. Hope that helps. Cheers, Ralf
Re: Question about automake fails to pass the correct parameters to pax when using large UID/GID
Hello Xufeng Zhang, thanks for the report. * xufeng zhang wrote on Wed, Oct 27, 2010 at 05:24:18AM CEST: I'm a developer from WindRiver, and I have a question about automake. When I using a large UID/GID(2097151) to configure and build a linux project, gnu tar fails and automake select pax as a replacement. However, automake seems fail to pass the correct parameters to pax(we are using ustar as archive format), the build hangs at: [...] checking how to create a ustar tar archive... ATTENTION! pax archive volume change required. Ready for archive volume: 1 Input archive name or . to quit pax. Archive name I think the problem is caused by the maximum limitation of UID/GID for ustar archive format (Maximum value of UID/GID is 2097151). So if it is proper to increase the limitation for UID/GID in ustar? I don't know if there is any considerations for this limitation? I don't think there is much that can be done about this in Automake, as that seems to be a limitation inheren in the ustar format. See info Automake --index 'ustar format' and the link to the Formats node of the GNU tar manual a couple of paragraphs further down. IIUC then you'd either have to change to a different UID/GID with lower values, or modify the package to use a different archive format. If you still think that Automake is in the position to do something about this, then please provide more details (as I'm not exactly an expert in archive formats portability). Thanks, Ralf
Re: ax_lib_mysql.m4 and -as-needed flag
Hello Sergio, * Sergio Belkin wrote on Mon, Oct 25, 2010 at 07:44:20PM CEST: I am using ax_lib_mysql.m4 in order to detect location of mysql libs, but the problem is that LD_FLAGS is a mixed if LD_FLAGS and LIBS: -rdynamic -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lssl -lcrypto The problem is that I want only link against mysqlclient, so I want to add --as-needed be honored, how can I do that? Put -Wl,--as-needed before the whole list, and -Wl,--no-as-needed afterwards? I should note that this will not work if you're linking with libtool and creating a shared library (which is a bug/limitation in libtool). Hope that helps. Cheers, Ralf
Re: using autoconf with ppuxlc++,spuxlc++
Hello John, * Eric Blake wrote on Wed, Oct 27, 2010 at 01:18:59AM CEST: On 10/26/2010 04:31 PM, John Wohlbier wrote: We're trying to use autoconf in a hybrid environment that includes the CellBE. I have a configure.ac for the CellBE PPE core and one for the SPE core. I also have some macros for setting up the compilers and their flags since it appears that AC_PROG_CC and AC_PROG_CXX do not support these compilers. I have what I feel are valid compiler flags for, in this case, ppuxlc++. However, I think I have a problem with the interaction of autoconf/libtool and cannot get my sources to compile. Below is what I see on output. To try and narrow down on the error ppuxlc++: 1501-208 (S) command option D is missing a subargument I went through by hand and removed all of the -D arguments, and it still failed. Finally, I removed the -MD argument and it compiles. Unfortunately I don't know enough about autoconf/libtool to know what the -MD -MP -MF arguments are or where they come from. Can anyone provide any hints or suggestions on how to figure out what is going on? How exactly do you invoke configure, what does configure output as dependency mechanism for these two compilers, where are the manpages for the compilers? Thanks, Ralf
Re: Using -MMD instead of -MD for depndency generation
Hello Holger, * Holger Freyther wrote on Mon, Oct 25, 2010 at 09:39:29AM CEST: On 10/25/2010 08:09 AM, Ralf Wildenhues wrote: * Holger Freyther wrote on Sat, Oct 23, 2010 at 10:47:47PM CEST: when typing make in the build directory of WebKit/GTK+ it takes multiple minutes until the first file is compiled. Can you go into (a lot) more detail here? What happens during those minutes, which processes are running (look at ps output etc.)? I am talking about executing make after the source has been built once. E.g. there is only one file changed and I want to rebuild the library with this single new file. My benchmark is to type 'time make' on unchanged source. From my expectation it will parse the GNUmakefile and all the files (the .Plo, Po with the dependencies) included by it, then it needs to verify the dependencies of all these rules for the 'all' target and then exits. Right now this takes 5:42m usertime (+- 10 seconds). OK. That's a lot. My half-stable-half-testing system needs some love to build webkit OOTB so I can't provide comparison data yet. Is this cold-cache or hot-cache? Only the first time the code is compiled, or the build tree is used, i.e., does it happen again after 'make clean'? Or are you talking about configure (-q?) run time here? My system is a MSI X340 with a U7300 @ 1.30GHz and had about 2GB of RAM available, it is running 2.6.36rc8 (but all kernels have shown this behavior) on a Fedora F14 installation. GNU make is of version 3.82, automake is 1.11.1. This is with a 'hot-cache' but with only 2GB of RAM not every file will fit into the page cache. The disk speed is quite okay, slowed down a bit due dm-crypt. The system is not loaded at all, it runs a wm, some gnome-terminals with remote ssh sessions, when executing make it will be the process that takes 99% of the CPU. Have you tried moving the build tree to a ramdisk (/dev/shm)? Do you use the noatime or relatime mount option? If not, please seriously consider doing so on mount points where you keep temporary data (not your mail folders!). For most effective edit-compile-test cycle, I typically move to a big system with lots of RAM and use make -jN with the build tree (not necessarily the source tree) on ramdisk and optionally also use ccache and/or distcc (if the system is not that big). I've found the ramdisk to make file system accesses fairly irrelevant. Eventually, the right answer to lots of file accesses for builds this size or larger is to use a beta build system. I hope somebody ports tup to GNU make syntax, or extends GNU make to have tup-like functionality. If the above all doesn't help make your problem irrelevant, I might be willing to look into optionally going for -MMD instead of -MD, but I do think that from a correctness POV it is not the right thing. If your installed software changed, then you need to also rebuild. Cheers, Ralf
Re: Using -MMD instead of -MD for depndency generation
Hello Paul, * Paul Smith wrote on Wed, Oct 27, 2010 at 10:25:03PM CEST: I downloaded the tarball you linked to, to my system but wasn't able to build; it configured and built about half the code, then failed: CXX WebKit/gtk/WebCoreSupport/libwebkitgtk_1_0_la-FullscreenVideoController.lo WebKit/gtk/WebCoreSupport/FullscreenVideoController.cpp:32: fatal error: gst/gst.h: No such file or directory Rerun with 'make V=1' to see the command that causeed the failure. Anyway, with half the tree built (I think): webkit-1.3.5$ find -name \*.o | wc -l 1437 make 3.81 takes about 8 seconds on my system to get back to trying to build the above file, and failing. I do notice that make 3.82 takes a lot longer (23s !!) so there's definitely something I need to check out in that respect. But 5m seems pretty crazy. Agreed. Thanks for sharing this data! Ralf
Re: Using -MMD instead of -MD for depndency generation
Hello Holger, thanks for the report. * Holger Freyther wrote on Sat, Oct 23, 2010 at 10:47:47PM CEST: when typing make in the build directory of WebKit/GTK+ it takes multiple minutes until the first file is compiled. Can you go into (a lot) more detail here? What happens during those minutes, which processes are running (look at ps output etc.)? Is this cold-cache or hot-cache? Only the first time the code is compiled, or the build tree is used, i.e., does it happen again after 'make clean'? Or are you talking about configure (-q?) run time here? What system is this on, is it very loaded with other processes? Can you please post a link to the tarball you're compiling from, so we can try to reproduce this? I would like to reduce the size of the .Plo (dep files) in my build tree and build them with -MMD instead of -MD. Is there a way to instruct automake to use -MMD for gcc3 like depmode? No, there isn't, but also, in my experience, that will not help all that much at all. All files listed as dependencies with -MD will be opened anyway by the compiler eventually, and a list of files usually won't amount to sizeable file size. I'm still guessing that it's something else that slows down your build by so much. Thanks, Ralf
Re: Feature Request: all-hook
Hello Luiji, * Luiji Maryo wrote on Fri, Oct 22, 2010 at 01:51:35AM CEST: Could you please implement an all-hook? Currently, I have UPX compress the executable after installation, however I find it would be much more useful if it were compressed after compilation. Is there a reason there is no all-hook? Is there an alternative way to do this (such as some sort of compile-hook)? We could add all-hook if someone can demonstrate that it would be useful. I don't completely understand your request, but you could probably either use an all-local rule that simply depends upon $(bin_PROGRAMS) (or similar) so that it is run after they have been updated. Alternatively, if you are going to modify programs in place, then the only way to sanely do that would be to overwrite the automake- generated link rule. Rationale is the following: if your compression modifies the programs in place, then a 'make -j check' might try to access half-modified programs while running tests already, or other rules depending on your programs might access them. Remember that you shouldn't cheat 'make' by modifying files outside of their rules, if you can help it. Cheers, Ralf
Re: check_PROGRAMS LDADD
Hello Patrick, please don't top-post, thank you. * Patrick M. Rutkowski wrote on Thu, Oct 21, 2010 at 11:55:28PM CEST: On Thu, Oct 21, 2010 at 4:17 PM, NightStrike wrote: On Wed, Oct 20, 2010 at 1:01 AM, Ralf Wildenhues wrote: * Patrick Rutkowski wrote on Wed, Oct 20, 2010 at 03:26:52AM CEST: As the collection of tests grows it's going to get annoying to have to add an _LDADD entry for every single one separately. Is it possible to add an _LDADD for all check_PROGRAMS items in one blow? All *_PROGRAMS that don't have an *_LDADD override use plain LDADD: LDADD = -lquark Is there any _PROGRAM that isn't a check_PROGRAM? Good question. At this very moment, no, there aren't any other programs. But there might potentially be other programs in the future. And I'd still really love to know if there's less blanket-cover way to do it than the global LDADD. At that point you can either specify all check programs in a separate Makefile.am, say tests/Makefile.am, and set LDADD differently in that, or you can set the prog_LDADD for one or both of the sets. Currently, check_PROGRAMS, bin_PROGRAMS, and noinst_PROGRAMS only differ in *when* their rules are triggered, not in how they are built when they are built. I really would like to keep it that way, because everything else is fairly insane wrt. implementation (cf. lib_LTLIBRARIES vs. pkglib_LTLIBRARIES which need '-rpath target_dir' passed), esp. when it comes to things like conditionals. Hope that helps. Cheers, Ralf
Re: User extensions
Hello Stefano, Valentin, please discuss patches on the -patches list; and please keep the original poster in Cc:, thanks. I haven't looked at the patch in detail yet, but will, now that the assignment papers are done (thanks!). * Stefano Lattarini wrote on Sat, Oct 23, 2010 at 04:05:02PM CEST: On Friday 03 September 2010, Valentin David wrote: * --libdir= can be called several times, the arguments can also have a list of paths separated by a colon. We should really use the system PATH separator here, for better portability (such PATH separator is already computed and AC_SUBST'd by configure as `...@path_separator@'). Why would an arbitrary path, having nothing to do with the PATH environment variable, needlessly have the same system-dependent separator? Other paths don't do this, either. Thanks, Ralf
Re: check_PROGRAMS LDADD
Hello Patrick, * Patrick Rutkowski wrote on Wed, Oct 20, 2010 at 03:26:52AM CEST: test_avl_avl_iter_test_LDADD= -lquark test_avl_avl_test_LDADD = -lquark test_unicode_unicode_test_LDADD = -lquark === As the collection of tests grows it's going to get annoying to have to add an _LDADD entry for every single one separately. Is it possible to add an _LDADD for all check_PROGRAMS items in one blow? All *_PROGRAMS that don't have an *_LDADD override use plain LDADD: LDADD = -lquark Cheers, Ralf
Re: dependency list ...
Hello, * Teratux wrote on Tue, Oct 19, 2010 at 10:22:15PM CEST: Hi, I was wondering how to know the build dependencies for a package before building it ... For example I would like to build a package and not get any fuss about unmet dependencies. Is there a way to print a list of package dependencies to meet before building it ?? No, that infrastructure doesn't yet exist in a systematic way. But we would like to change that eventually and invent something like it: http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/13203 Contributions welcome. Cheers, Ralf
