Re: configure: WARNING: `missing' script is too old or missing
Hello, * YuGiOhJCJ Mailing-List wrote on Sat, Aug 28, 2010 at 12:13:51PM CEST: When I run the configure script I get this warning : --- [...] checking whether build environment is sane... yes /bin/sh: /home/yugiohjcj/missing: No such file or directory configure: WARNING: `missing' script is too old or missing checking for a thread-safe mkdir -p... /usr/bin/mkdir -p [...] --- It is right /home/yugiohjcj/missing doesn't exists but I don't know why the configure script try to get this file in my home directory instead of my working directory. Which directory are you building in, and how exactly are you calling configure? Copy and paste, please, thanks. Do you have a line like AC_CONFIG_AUX_DIR([.]) in your configure.ac? Do you call AC_CONFIG_SRCDIR with a suitable file name as argument? The issue is probably that configure is confused as to finding the correct value of $srcdir, or that your tree is missing some helper scripts which you can probably get installed by calling automake --add-missing Hope that helps. Cheers, Ralf
Re: configure: WARNING: `missing' script is too old or missing
Hello, * YuGiOhJCJ Mailing-List wrote on Sat, Aug 28, 2010 at 05:04:54PM CEST: On Sat, 28 Aug 2010 15:19:30 +0200 Ralf Wildenhues wrote: * YuGiOhJCJ Mailing-List wrote on Sat, Aug 28, 2010 at 02:41:50PM CEST: In my configure.ac file, I don't use AC_CONFIG_AUX_DIR or AC_CONFIG_SRCDIR because these macros are not used in the sample HelloWorld Now, do you understand why the configure script doesn't found my missing script? Yes, thank you. Please move the AM_INIT_AUTOMAKE call up before AC_PROG_CC, then things will work. Hmm, maybe we should warn about this ordering issue, lemme see ... Thanks for reporting! Ralf
Re: [PATCH] Fix bug in test missing6.test
Hello, * Eric Blake wrote on Fri, Aug 27, 2010 at 07:10:47PM CEST: On 08/27/2010 10:30 AM, Stefano Lattarini wrote: (Just for the record, I found this bug while running the automake testsuite with CONFIG_SHELL=dash). Out of curiosity, which version of dash? dash 0.5.6 has $LINENO support, but 0.5.5.1 still lacks it. Shells that lack $LINENO are getting rarer these days. At any rate, even though I just fixed autoconf to avoid the problem in the first place, you would have to wait until the new autoconf is widely available enough, so your patch is still worthwhile. Yes, I agree. The patch is ok for maint. An Autoconf testsuite addition m4_defining all single characters to something and then calling a bunch of Autoconf macros might be fun. Or, not. You really don't want to use maximal quoting everywhere unless forced to. Thanks, Ralf
Re: convert a pattern rule to a suffix rule
Hello, please don't top-post on this mailing list, thak you. * YuGiOhJCJ Mailing-List wrote on Thu, Aug 26, 2010 at 09:43:44AM CEST: On Wed, 25 Aug 2010 20:37:04 +0200 Ralf Wildenhues wrote: * YuGiOhJCJ Mailing-List wrote on Wed, Aug 25, 2010 at 11:14:15AM CEST: But we can use a old fashioned suffix rule which is portable. The problem is when the prerequisites arn't in the same directory than the target and when the prerequisites have no suffix. Then you cannot use suffix rules in a portable way, unfortunately; you can get around the directory fairly portably by setting something like VPATH = @srcdir@:../src:@srcdir@/../src in the Makefile.am and then forget about the directory (but you need a new Autoconf for this to work because we recently found an Autoconf bug in this area), but single suffix rules work the other way round; see for example `info Autoconf Single Suffix Rules'. If you don't want to require GNU make, the only fully portable way I know is to spell out the rule for each target. You say pattern rules and suffix rules are not portable. Also, the only way to be portable is to to spell out the rule for each target. So, can you tell me why autoreconf complains only when I use pattern rules and not when I use suffix rules? There is a misunderstanding here. I did not mean to say that suffix rules in general are not portable. Suffix rules in general are portable. However, for your specific issue, portable suffix rules do not suffice for two reasons: 1) the directory prefix, 2) the empty target suffix. (1) is fixable by VPATH means, (2) is not fixable portably. So, for the *specific situation* which you described, per-target rules are the only fully portable alternative. You are right that automake does not complain about the (1) and (2) types of unportabilities, because, well, there is just no way to spell out (2) with suffix rules. Hope that helps. Cheers, Ralf
Re: order of variables and rules in output
Hi Ben, * Ben Pfaff wrote on Wed, Aug 25, 2010 at 07:22:58PM CEST: Current Automake appears to reorder the Makefile.am so that all variable assignments precede all rules, so in a Makefile.am the relative order of variable and rule definitions does not matter. Right. Is this behavior documented? I thought so, but can't find it right away now. In any case, we cannot guarantee to *not* reorder because the flattening of += and the expansion of conditionals would probably not work otherwise. Is it guaranteed to remain in the future? I could not easily find mention of it in the manual, but it is sometimes convenient. Yes, that is the intention, and yes, I agree that it is convenient. Thanks, Ralf
Re: convert a pattern rule to a suffix rule
Hello, * YuGiOhJCJ Mailing-List wrote on Wed, Aug 25, 2010 at 11:14:15AM CEST: I know that pattern rules are not portable. When we use one pattern rule, then we call autoreconf, we can see this warning : man/Makefile.am:8: `%'-style pattern rules are a GNU make extension So if we want a protable project, we should not use them in a Makefile.am file. Or you use -Wno-portability to silence the warning, and require GNU make for building your project. But we can use a old fashioned suffix rule which is portable. The problem is when the prerequisites arn't in the same directory than the target and when the prerequisites have no suffix. Then you cannot use suffix rules in a portable way, unfortunately; you can get around the directory fairly portably by setting something like VPATH = @srcdir@:../src:@srcdir@/../src in the Makefile.am and then forget about the directory (but you need a new Autoconf for this to work because we recently found an Autoconf bug in this area), but single suffix rules work the other way round; see for example `info Autoconf Single Suffix Rules'. If you don't want to require GNU make, the only fully portable way I know is to spell out the rule for each target. Hope that helps. Cheers, Ralf
Re: linux to windows cross compile af a dll
Hello, * Eric Blake wrote on Tue, Aug 24, 2010 at 06:47:51PM CEST: On 08/24/2010 10:42 AM, Joost Kraaijeveld wrote: *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. It seems to be related to http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/libtool.html Is the hack that is mentioned necessary or is there another solution? Which ./libtool --version is your package using? With 2.2.10, no hacks should be necessary. If 2.2.10 is still not working right, please post the output of the failing 'libtool --mode=link' command, with --debug added as first argument after libtool. Thank you. Replies can drop the automake list from Cc:. Cheers, Ralf
Re: [PATCH] Enable `set -e' in more tests (plus some tweakings).
Hi Stefano, * Stefano Lattarini wrote on Sun, Aug 22, 2010 at 03:10:54PM CEST: This patch shouldn't cause problems, as the modified tests do not use shell functions nor complex shell constructs, loops or conditionals (with the exception of `info.test', but see the FIXME comment added to it). Please state if and how you tested the 'set -e' patches (e.g., Solaris shell, heirloom shell, etc). That helps immensely for reviewing them. Thanks! Ralf
Re: On Ubuntu 10.4, test programs that segfault do XPASS
* Roberto Bagnara wrote on Sun, Aug 22, 2010 at 09:36:34AM CEST: On 08/22/10 06:11, Ralf Wildenhues wrote: * Roberto Bagnara wrote on Sat, Aug 21, 2010 at 11:32:45PM CEST: I have three programs that, due to a buggy program transformation, keep allocating stack space until they segfault: $ ulimit -s 8192 $ ./bug23 Segmentation fault [...] However: $ make check ... XPASS: bug23 I am able to reproduce this _only_ on Ubuntu (10.4): on all other systems I have access to things work as expected. Thanks for the data, unfortunately I still have no clue. The fact that both dash and bash fail looks like it could be a libc or kernel issue. Can you post (gzip'ed) trace of strace -f -o trace make check SHELL='/bin/bash -x' TESTS=bug23 and maybe make the package available so we can try it out? Thanks, Ralf
Re: [PATCH 1/6] Test that aclocal(s) used by the testsuite and by autoconf match.
Hi Stefano,
you don't make it easy to catch up with you! :-O
* Stefano Lattarini wrote on Thu, Aug 19, 2010 at 02:54:52PM CEST:
* tests/remake0.test: New test.
* tests/Makefile.am (TESTS): Updated.
OK with ...
--- /dev/null
+++ b/tests/remake0.test
@@ -0,0 +1,38 @@
+# Make sure the autoconf used by $ACLOCAL and the autoconf used by the
... either s/the$// here, or
+# Automake's testsuite match. This is mostly a sanity check for the
s/'s// here.
+# Automake's testsuite, and its failure is an indication that the others
s/'s// s/ and / / s/others/other/
+# tests (especailly other `remake*.test' tests) might experience spurious
s/especailly/especially/
+# problems.
+
+. ./defs || Exit 1
+
+set -e
+
+: Makefile.am
+
+$ACLOCAL 2stderr || { cat stderr 2; Exit 1; }
+cat stderr 2
+grep -i 'warning.*generated for autoconf' stderr Exit 1
+grep -i 'another version of autoconf' stderr Exit 1
Is it possible to have a warning here already? How?
If not, please add a short comment before these two lines
that this is not expected to happen.
+$AUTOCONF 2stderr || { cat stderr 2; Exit 1; }
+cat stderr 2
+grep -i 'warning.*generated for autoconf' stderr Exit 1
+grep -i 'another version of autoconf' stderr Exit 1
I can see that a warning might happen here.
Thanks!
Ralf
Re: [PATCH 4/6] Improve support for non-default autotools in rebuild rules.
* Stefano Lattarini wrote on Thu, Aug 19, 2010 at 03:05:20PM CEST: --- a/m4/init.m4 +++ b/m4/init.m4 @@ -70,10 +70,22 @@ _AM_IF_OPTION([no-define],, # Some tools Automake needs. AC_REQUIRE([AM_SANITY_CHECK])dnl AC_REQUIRE([AC_ARG_PROGRAM])dnl +dnl We pass the the $AUTOCONF and $AUTOM4TE commands in the environment +dnl of automake and aclocal calls in the generated Makefiles, so wrapping +dnl them with the `missing' script would defintely be a bad idea. typo defintely +dnl For example, if aclocal proper is ever called, it will need a working +dnl autom4te to get traces from e.g. configure.ac, and in such a case the +dnl workarounds provided by `missing --run autom4te' are not enough; a +dnl flat-out aclocal failure is the best and most correct option. Hmm, but a slightly version-skewed autom4te for tracing should usually be ok. The tracing algorithm hasn't been very version-sensitive in the past. Does this make sense what I'm saying or is this remark off the mark? (I haven't grokked your complete patch series yet.) Thanks, Ralf
Re: [PATCHES] Docs on automatic dependency tracking
* Stefano Lattarini wrote on Wed, Aug 18, 2010 at 12:14:03PM CEST: Applied to maint, merged in master and branch-1.11, and pushed. FWIW, somehow you managed to apply these two patches separately to each of these branches, instead of merging them all from maint. I'm fixing the merges with the next push. Cheers, Ralf
Re: [PATCH 2/6] Testsuite: fix missing*.test for non-default autotools.
* Stefano Lattarini wrote on Sat, Aug 21, 2010 at 01:00:46PM CEST: On Saturday 21 August 2010, Ralf Wildenhues wrote: What is the actual problem by the way? Basically, `missing --run /abs/path/to/autoconf' does not recognize the program being run as an autoconf: Why not adjust `missing' instead? Thanks, Ralf
wikipedia
Apologies for the slightly off-topic message, but the German wikipedia entry for autotools contains a number of inaccuracies and bias against it. I consider myself biased so I won't edit it, but would be delighted to see someone setting things straight, trying to avoid bias. If you have questions feel free to ask. Thanks, Ralf
Re: make clean is slow
So long ago already ...
* Bob Friesenhahn wrote on Wed, Oct 21, 2009 at 10:26:14PM CEST:
On Wed, 21 Oct 2009, Ralf Wildenhues wrote:
Is there a way to make this quite a lot faster?
The LTLIBRARIES bits: yes, noted. The PROGRAMS bits should be
reasonably fast already, only forking a constant number of times.
While clean is running, it is clear that the libraries bit is taking
most of the time. My package has quite a lot of these files to
remove, and the sequential nature of the removal process causes it
to be rather slow.
The time to clean my package depends quite a lot on the OS:
FreeBSD: 1.512
OS-X Leopard: 3.575
Solaris 10: 4.339
Linux (under Solaris VirtualBox): 4.299
MinGW:6.656
For some of the OSs the time is about the same if the directory is
already cleaned, while for others (e.g. OS-X) the time improves
considerably if the directory is already clean.
Here's a first patch I'm merging to master. It speeds up removal of the
so_locations files, getting me 30% faster 'make clean' overall with
your package.
It is not the whole story: object files are still cleaned in a slow way.
For another patch.
Cheers,
Ralf
Speed up removal of auxiliary linker output files for ltlibraries.
* lib/am/ltlib.am (clean-%DIR%LTLIBRARIES): Rewrite using just
one `rm' invocation.
Report by Bob Friesenhahn.
diff --git a/lib/am/ltlib.am b/lib/am/ltlib.am
index 29aa00c..55e53e1 100644
--- a/lib/am/ltlib.am
+++ b/lib/am/ltlib.am
@@ -104,9 +104,11 @@ clean-%DIR%LTLIBRARIES:
## `so_locations' files are created by some linkers (IRIX, OSF) when
## building a shared object. Libtool places these files in the
## directory where the shared object is created.
- @list='$(%DIR%_LTLIBRARIES)'; for p in $$list; do \
- dir=`echo $$p | sed -e 's|/[^/]*$$||'`; \
- test $$dir != $$p || dir=.; \
- echo rm -f \$${dir}/so_locations\; \
- rm -f $${dir}/so_locations; \
- done
+ @list='$(%DIR%_LTLIBRARIES)'; \
+ locs=`for p in $$list; do echo $$p; done | \
+ sed 's|^[^/]*$$|.|; s|/[^/]*$$||; s|$$|/so_locations|' | \
+ sort -u`; \
+ test -z $$locs || { \
+ echo rm -f $${locs}; \
+ rm -f $${locs}; \
+ }
Re: On Ubuntu 10.4, test programs that segfault do XPASS
Hello Roberto, * Roberto Bagnara wrote on Sat, Aug 21, 2010 at 11:32:45PM CEST: I am using Automake's simple test driver. Are you using parallel-tests or not? Any setting for the variables TESTS_ENVIRONMENT, LOG_COMPILER? I have three programs that, due to a buggy program transformation, keep allocating stack space until they segfault: $ ulimit -s 8192 $ ./bug23 Segmentation fault [...] However: $ make check ... XPASS: bug23 I am able to reproduce this _only_ on Ubuntu (10.4): on all other systems I have access to things work as expected. Please show ./bug23; echo $? as well as /bin/dash -c './bug23; echo $?' and also make check SHELL='/bin/dash -x' TESTS=bug23 (replace /bin/dash with whatever SHELL is assigned to in your Makefile). Thanks, Ralf
Improve robustness of mdate-sh script.
I managed to get SHELL=.../zsh in some weird configuration of some
unrelated package (m4 on AIX in this case, but I've seen this issue
elsewhere and in other packages before), and it caused mdate-sh to loop
endlessly, trying to shift nonexistent positional parameters in the hope
of finding a date to parse.
This patch fixes both the underlying issue (zsh emulation mode) as
well as making the script a bit more robust and reliable wrt. errors.
Pushing to maint.
Thanks,
Ralf
Improve robustness of mdate-sh script.
* lib/mdate-sh: Sanitize zsh behavior on startup, to ensure
$ls_command is word-split properly upon invocation.
(error): New function.
(main): Use it. Improve error checking to avoid endless loop
in case $ls_command gave bogus output. Fix eval quotation.
* tests/mdate6.test: New test, to expose eval quotation error.
* tests/Makefile.am: Update.
diff --git a/lib/mdate-sh b/lib/mdate-sh
index c477512..60dc485 100755
--- a/lib/mdate-sh
+++ b/lib/mdate-sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Get modification time of a file or directory and pretty-print it.
-scriptversion=2010-02-22.21; # UTC
+scriptversion=2010-08-21.06; # UTC
# Copyright (C) 1995, 1996, 1997, 2003, 2004, 2005, 2007, 2009, 2010
# Free Software Foundation, Inc.
@@ -29,6 +29,15 @@ scriptversion=2010-02-22.21; # UTC
# bugs to bug-autom...@gnu.org or send patches to
# automake-patches@gnu.org.
+if test -n ${ZSH_VERSION+set} (emulate sh) /dev/null 21; then
+ emulate sh
+ NULLCMD=:
+ # Pre-4.2 versions of Zsh do word splitting on ${1+$@}, which
+ # is contrary to our usage. Disable this feature.
+ alias -g '${1+$@}'='$@'
+ setopt NO_GLOB_SUBST
+fi
+
case $1 in
'')
echo $0: No file. Try \`$0 --help' for more information. 12
@@ -51,6 +60,13 @@ EOF
;;
esac
+error ()
+{
+ echo $0: $1 2
+ exit 1
+}
+
+
# Prevent date giving response in another language.
LANG=C
export LANG
@@ -100,6 +116,7 @@ month=
command=
until test $month
do
+ test $# -gt 0 || error failed parsing \`$ls_command /' output
shift
# Add another shift to the command.
command=$command shift;
@@ -119,8 +136,10 @@ do
esac
done
+test -n $month || error failed parsing \`$ls_command /' output
+
# Get the extended ls output of the file or directory.
-set dummy x`eval $ls_command \\$save_arg1\`
+set dummy x`eval $ls_command $save_arg1\`
# Remove all preceding arguments
eval $command
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 0558149..3ecc341 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -474,6 +474,7 @@ mdate2.test \
mdate3.test \
mdate4.test \
mdate5.test \
+mdate6.test \
missing.test \
missing2.test \
missing3.test \
diff --git a/tests/Makefile.in b/tests/Makefile.in
index a06026e..4671ad0 100644
--- a/tests/Makefile.in
+++ b/tests/Makefile.in
@@ -712,6 +712,7 @@ mdate2.test \
mdate3.test \
mdate4.test \
mdate5.test \
+mdate6.test \
missing.test \
missing2.test \
missing3.test \
diff --git a/tests/mdate6.test b/tests/mdate6.test
new file mode 100755
index 000..e7f7d69
--- /dev/null
+++ b/tests/mdate6.test
@@ -0,0 +1,35 @@
+#! /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/.
+
+# mdate-sh can work with weird file names, doesn't eval too much.
+
+. ./defs || Exit 1
+
+set -e
+
+a=
+file='file name $a'
+( : $file ) || Exit 77
+
+cp $testsrcdir/../lib/mdate-sh .
+$SHELL ./mdate-sh $file stdout 2stderr ||
+ { cat stdout; cat stderr 2; Exit 1; }
+cat stdout
+cat stderr 2
+grep '[12][0-9]\{3\}' stdout
+test ! -s stderr
+
+:
Re: Linking libraries problem
Hello Jesús, * Jesús wrote on Fri, Aug 20, 2010 at 05:37:58PM CEST: make[4]: *** No rule to make target `libA.la', needed by `libB.la'. Stop. * Makefile for libB (simplified): INCLUDES = -I$(top_srcdir)/dirA lib_LTLIBRARIES = libB.la libB_la_SOURCES = srcB.c srcB.h libB_la_LDFLAGS = @LIBB_FLAGS@ libB_la_LIBADD = libA.la Change this last line to be something like libB_la_LDADD = ../liba-directory/liba.la if '../liba-directory' is the relative path from the directory in which libB is created to the directory in which libA is created. Then all should be well. :-) Hope that helps. Cheers, Ralf
Re: automake-1.11.1 test results on old OSF/1
Hello Jay, * Jay K wrote on Thu, Aug 19, 2010 at 09:34:50PM CEST: = http://modula3.elegosoft.com/cm3/uploaded-archives/testlogs.tar.gz Thanks. You have GNU coreutils in your $HOME/bin I bet, but it looks like it's a fairly old version; no non-GNU cp uses `quoting' in its error reporting, and coreutils seems to have changed the output format around 10 years ago. Any chance you could update? Or it's the shell or make that mess it all up. Note: this is old even for OSF/1, being 5.1, not 5.1a, 5.1b, 5.1f, etc. My last testing of some git Automake on OSF 5.1 had only two (different) failures, and I usually try to test system tools only. Cheers, Ralf make[2]: Leaving directory `/home/jayk/obj/automake/tests' make check-TESTS make[2]: Entering directory `/home/jayk/obj/automake/tests' Stack overflow: pid 14948, proc ksh, addr 0x11de0, pc 0x3ff801bbf28 make[3]: Entering directory `/home/jayk/obj/automake/tests' FAIL: distdir.test FAIL: extra5.test FAIL: extra6.test FAIL: extra7.test FAIL: fn99.test FAIL: fn99subdir.test FAIL: nobase-libtool.test
Re: [PATCHES] Two small improvements to HACKING
* Stefano Lattarini wrote on Thu, Aug 19, 2010 at 12:23:47PM CEST: On Thursday 19 August 2010, Ralf Wildenhues wrote: Are you aware that merging fix-foo in maint, branch-1.11, and master is equivalent to merging fix-foo in maint, then merging maint in branch-1.11 and master (under the assumption that prior to the fix, maint was an ancestor of branch-1.11 and master)? Yes. Good. :-) Moreover, an avarage git user with pushing right should know what you explained above, i.e. that... merging fix-foo in maint, branch-1.11, and master is equivalent to merging fix-foo in maint, then merging maint in branch-1.11 and master (under the assumption that prior to the fix, maint was an ancestor of branch-1.11 and master)? ... while the usefulness of the bug-fixing-through-branching policy you are using for automake might not be obvious (it wasn't for me until your explanation in a previous mail). In light of these considerations, is my wording acceptable? Yes, sure. [ reordered ] P.S. When you said ... If no, this paragraph should be rewritten, if yes, then how come you didn't just merge maint into branch-1.11 and master? ;-) ... were you asking why I didn't do that in my last push? Yep. Well, because I find an explicit merge of the bug-fixing branch in all the affected branches clearer: it's like saying Hey, I'm doing this merge to fix a bug!, while this is unclear in a merge of e.g. maint. Good argument. Please complain if you feel I'm giving you too much of a hard time. My impression is that it improves your patches and your argumentation. :-) Cheers, and thanks for persisting, Ralf
Re: Testing a new compiler with Automake simple tests
* Stefano Lattarini wrote on Thu, Aug 19, 2010 at 04:39:29PM CEST: On Wednesday 18 August 2010, Ralf Wildenhues wrote: I suppose automake could be enhanced to also define $(OBJECTS) as the set of all objects. What about libtool objects? Should we care about them? I'm writing a couple of (xfailing) testcases to check a prospective patch introducing $(OBJECTS) (BTW, is such a general name enough namespace-safe? I hardly think so...), and I don't know what to do for libtool objects. At this point I'm not sure if it's safe or worthwhile to add either of them. This is a pretty special case here, and we don't really have much use for this otherwise, do we? Generally, I think the idea a couple of years ago was to move away from the all-collecting variables such as $(SOURCES), $(PROGRAMS) etc. Haven't dug history to find out for sure why, though. Cheers, Ralf
Re: [PATCH] Fix potential regressions in depcomp{3,5}.test.
Hi Stefano,
* Stefano Lattarini wrote on Wed, Aug 18, 2010 at 02:50:50PM CEST:
The attached patch fix a potential regression in a couple of tests,
introduced my recent patch Minor improvements and fixes in tests
`depcomp*.test'.
OK to push to maint ASAP?
Ideally, you'd commit this to a temporary branch based off of the patch
that introduced the regression, and merge that branch into maint.
If we follow this strategy consistently, then there one can simply
merge the temp branch into all branches that have the parent. There
is a git one-liner for finding out this set but I forgot it now.
There is no need for hurry, all greps we know treat \o the same as o.
Thanks,
Ralf
Subject: [PATCH] Fix potential regressions in depcomp{3,5}.test.
* tests/depcomp3.test: Do not uselessly escape the character `$'
in makefile rules, when it's used to expand a make macro.
* tests/depcomp5.test: Likewise.
Re: [PATCHES] Two small improvements to HACKING
* Stefano Lattarini wrote on Thu, Aug 19, 2010 at 12:09:15AM CEST: HACKING: improve description of git bugfix branches. HACKING: acknowledge Perl 4 as utterly obsolete. Nits below. Subject: [PATCH 1/2] HACKING: improve description of git bugfix branches. * HACKING (Working with git): Extend and make less terse the description of git bugfix branches. grammar: ... and make the description of ... less terse. or just: Extend. --- a/HACKING +++ b/HACKING @@ -139,9 +139,11 @@ # if all seems ok, then actually push: git push origin maint branch-1.11 master -* For bug fixes of long-standing bugs, it may be useful to commit them to - a new branch based off of the commit that introduced the bug, and merge - this bugfix branch into active branches that descend from the buggy commit. +* When fixing a bug (especially a long-standing one), it may be useful + to commit the fix to a new temporary branch based off the commit that + introduced the bug. Then this bugfix branch can be merged into all + the active branches descending from the buggy commit. This offers a + simple way to fix the bug consistently and effectively. Are you aware that merging fix-foo in maint, branch-1.11, and master is equivalent to merging fix-foo in maint, then merging maint in branch-1.11 and master (under the assumption that prior to the fix, maint was an ancestor of branch-1.11 and master)? If no, this paragraph should be rewritten, if yes, then how come you didn't just merge maint into branch-1.11 and master? ;-) Subject: [PATCH 2/2] HACKING: acknowledge Perl 4 as utterly obsolete. * HACKING (Editing automake.in and aclocal.in): Don't tell that Perl 5 is OK now: that's obvious! In fact, I'd be surprised to see anyone still using Perl 4... Let's keep our log entries concise, and no need to get excited in them. configure already requires 5.6, so this would have been sufficient, no? HACKING: Perl 4 is obsolete. * HACKING (Editing automake.in and aclocal.in): Remove note about Perl 5. Thanks, Ralf
Re: Testing a new compiler with Automake simple tests
* Stefano Lattarini wrote on Wed, Aug 18, 2010 at 03:42:01PM CEST: On Wednesday 18 August 2010, Roberto Bagnara wrote: On 08/18/10 13:18, Stefano Lattarini wrote: At Wednesday 18 August 2010, Roberto Bagnara wrote: #$(TESTS:=...@objext@): ../../bin/compiler The above is rejected even with the dot. This seems like an automake limitation... no big deal though, as there is the simple workaround: TESTS_OBJS = $(TESTS:=...@objext@) $(TESTS_OBJS): ../../bin/compiler which is also clearer to read IMO. Yeah, that's just an automake parsing buglet. it's better to do: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(t1_OBJECTS) $(t2_OBJECTS) $(t3_OBJECTS) \ $(t4_OBJECTS) $(t5_OBJECTS) $(t6_OBJECTS) $(TESTS_OBJS): ../../bin/compiler Unfortunately, this is more error-prone, since if you add, say, `t7' to TESTS, but forget to add $(t7_OBJECTS) to TESTS_OBJS, you'll have missing dependencies... Well, you'll decide what's better for you. Hmm, it is error-prone indeed. Moreover, we have more than one thousands tests and we could soon have two thousands of them. I suppose automake could be enhanced to also define $(OBJECTS) as the set of all objects. But there are other ways you could hack around this. Iff your compiler is generated from a different Makefile.am (this is important!), then in the tests/Makefile.am you could: BUILT_SOURCES = stamp-objects stamp-objects: ../../bin/compiler -rm -f *.$(OBJEXT) -rm -f sub/*.$(OBJEXT) ... echo timestamp $@ It is rather hacky, but it should work. Untested. Cheers, Ralf
Re: doc: misplaced sections about Emacs Lisp, Java, Python
Hi Bruno, thanks for the report! * Bruno Haible wrote on Sun, Aug 15, 2010 at 04:52:55PM CEST: In the Automake documentation, the sections Emacs Lisp, Java, Python are in a chapter Other GNU Tools, two chapters away from the sections C++ support, Objective C Support, Assembly Support, Java Support. It is somewhat confusing. I agree that it is a bit confusing. Esp. the Java splitting seems ugly. Suggestion: - Move the sections Emacs Lisp, Python to the chapter Building Programs and Libraries. - Combine the section Java with the section Java Support, possibly in two subsections, inside the chapter Building Programs and Libraries. I'm torn about this one. The short-hand for the Building Programs and Libraries chapter is Programs, and in the Automake naming scheme, _PROGRAMS are definitely not a super set of Python scripts nor Lisp sources. OTOH if we intend for the more general meaning of programs that may be executed, then I would expect to find scripts dealt with there as well, but they are discussed in the chapter in between. Furthermore, the Programs chapter is quite large the way it is already, and that we may want to add a couple more entries, too. Not a big issue of course, but doesn't add to a well-structured manual. I'm not quite sure about the best way out here. Cheers, Ralf
Re: [PATCHES] Docs on automatic dependency tracking (was: Testing a new compiler with Automake simple tests)
[ dropped automake@ ]
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 10:29:51PM CEST:
From ef90f67c33297b361ac9630fd5fa8be5d2e463d5 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Tue, 17 Aug 2010 19:23:47 +0200
Subject: [PATCH 1/2] Fix typo in manual (`Makefile.in' instead of
`Makefile.am').
* doc/automake.texi (Automatic dependency tracking): Ditto.
OK for maint, thanks. The Ditto is confusing though, making it seem
like there are two things that are fixed. Fix typo, or just use one
line of commit entry is fine in that case.
From e701a503993423ec559eb7b90135fe7dce724eef Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Tue, 17 Aug 2010 22:19:08 +0200
Subject: [PATCH 2/2] Docs: clarify how to avoid automatic dependencies
tracking.
* doc/automake.texi (Automatic dependency tracking): Tell that
automatic dependencies tracking is on by default, but that the
package developer can disable it altogether. Add a referencw
to the proper section for a more in-depth explanation.
s/Tell/Mention/ s/ on / enabled / s/referencw/reference/
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -1246,6 +1246,11 @@ source being compiled). Later, any time
@command{make} is run and a
dependency appears to have changed, the dependent files will be
rebuilt.
+By default, Automake generates code for such an automatic dependency
+tracking. Note, however, that the developer can override this, and
+avoid automatic dependency tracking altogether; see @ref{Dependencies}
+for more information.
Sounds a bit awkward. How about this slight rewording:
Automake generates code for automatic dependency tracking by default,
unless the developer chooses to override it; for more information,
@pxref{Dependencies}.
OK for maint if you agree.
Thanks,
Ralf
Re: [PATCHES] Docs on automatic dependency tracking
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 11:05:25PM CEST: So is: * doc/automake.texi (Automatic dependency tracking): Fix typo. acceptable? Sure. OK for maint if you agree. I agree, and I think I should add your name to the ChangeLog entry. OK? No need, but do however pleases you. Thanks, Ralf
Re: Testing a new compiler with Automake simple tests
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 02:26:13PM CEST: At Tuesday 17 August 2010, Roberto Bagnara wrote: On 08/17/10 13:26, Stefano Lattarini wrote: $(TESTS): your-special-purpose-compiler That dependency cases relinking whenever the compiler changes, whereas I need recompilation. Obviously you're right, sorry for not thinking this through. If every test program is built from a single `.c' file, what about using this instead: $(TESTS:=.o) your-special-purpose-compiler It should also be portable make AFAIK. This doesn't take into account that object file names are an internal detail of Automake. In practice, they might end in .obj, as Stefano already noted, which $(OBJEXT) or @OBJEXT@ can tell you, but also, object files may be renamed due to one of several reasons such as per-target flags, (obsolete) KnR support, and others. I'm mentioning @OBJEXT@ because $(TESTS:=$(OBJEXT)): compiler is not portable to some make implementations, while $(TESTS:=...@objext@): compiler is. Also, if your tests contain scripts as well, $(check_PROGRAMS:=...@objext@): compiler or EXTRA_PROGRAMS may be more correct. There are usually undocumented variables which hold the lists of objects which you could use but then be forced to check whether updating to a new Automake might have broken things (unlikely case, but possible). Do you know if there is a way I can force Automake to add a dependency on the compiler in the .c.o rule? That is, to generate: .c.o: my-special-purpose-compiler $(AM_V_CC) \ $(COMPILE) -c $ No, sorry; I don't even think it's possible (but I'm not sure about it, either). FWIW, it is not portable to all make implementations to specify dependencies to an inference rule. It should be done separately. Cheers, Ralf
pattern rules example (was: Makefile to Makefile.am)
[ automake-patches@ added; followups can drop automake@ ]
Hello Thien-Thi,
* Thien-Thi Nguyen wrote on Mon, Aug 16, 2010 at 02:22:31AM CEST:
() Ralf Wildenhues
() Sun, 15 Aug 2010 23:32:44 +0200
Yes, with a general example, please.
I am unsure what general example means, precisely, so
the patch below simply uses the one in The GNU Make Manual.
Is that ok?
The explanation is good, but there are a couple of reasons I'd prefer a
slightly different example: first, automake already generates rules for
compiling .c sources by itself, so this example should never be needed
for Automake users; then, the automake-generated rules are slightly
different: $(CPPFLAGS) come before $(CFLAGS), there are also the AM_*
or per-target flags, and .o might be .obj, giving rise to $(OBJEXT).
Further, there is the SUFFIXES variable to which suffixes should be
added when they are not of the default form.
Can we find a transformation that is known to most readers, not already
done by automake, general enough to be portable, and short enough to
serve as a quick example? If a real-world one can't be found, then we
can still use a fake .foo - .bar one.
Then, the placement of the description isn't optimal. The Multiple
Outputs node is specifically about creating multiple output files with
a single rule. A pattern example would better fit in the Suffixes
node; a cross reference from the Multiple Outputs node is a good idea
though, as in see @ref{...} for more discussion of pattern rules.
Thanks,
Ralf
Subject: [PATCH] Document a common conversion for GNU make pattern rules.
* doc/automake.texi (Multiple Outputs): Expand on GNU make
pattern rules; explain how to convert a common case to use
old-fashioned suffix rules; add simple example, xref.
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -11525,11 +11525,31 @@ @node Multiple Outputs
@c $$
For completeness it should be noted that GNU @command{make} is able to
-express rules with multiple output files using pattern rules
-(@pxref{Pattern Examples, , Pattern Rule Examples, make, The GNU Make
-Manual}). We do not discuss pattern rules here because they are not
-portable, but they can be convenient in packages that assume GNU
-...@command{make}.
+express rules with multiple output files using pattern rules.
+Although pattern rules are not portable, they can be
+convenient in packages that assume GNU @command{make}.
+...@xref{pattern Examples, , Pattern Rule Examples, make, The GNU Make
+Manual}.
+
+In the common case where the @samp{%} in the pattern rule is used to
+match the stem of a filename, and the prerequisite and target differ
+only in the filename extension, you can use the old fashioned suffix
+rule instead. For example:
+
+...@example
+# pattern rule, not portable
+%.o : %.c
+$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@@ $
+
+# old fashioned suffix rule, portable
+.c.o:
+$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@@ $
+...@end example
+
+Take care, when converting from pattern rule syntax to suffix rule
+syntax, to place the prerequisite extension @file{.c} before that
+of the target extension @file{.o}.
+...@xref{suffix Rules, , Old-Fashioned Suffix Rule, make, The GNU Make
Manual}.
GNU make or portable make? (was: Makefile to Makefile.am)
* Bob Friesenhahn wrote on Mon, Aug 16, 2010 at 05:06:40PM CEST: If depending on GNU make was considered ok, then Automake would have been developed quite differently than it is. Given current Automake objectives, it is wise that individual projects also try to avoid GNU make syntax in Makefile.am. While I don't dispute that, I do think that requiring GNU make is a fairly low barrier in way of prerequisites. GNU make is small, highly portable and easily installed. If Automake were only started now, I think requiring GNU make would be a prudent design decision. The current Automake code contains large chunks of logic that exists purely to work around missing features or issues in non-GNU make implementations. Let's be honest, requiring GNU make outright would make several optimizations possible, leading to smaller makefiles and lower build system overhead. We've been at the point before where some new feature was easily implemented in GNU make syntax but rather tough in portable make. Some features may not be possible at all with the latter. Still, as things stand, I'm not sure whether changing design goals of Automake now are such a good idea. BSD developers really like using their own make. The code we have works, build system overhead is really bad only on w32. We have opportunities for improvement by assuming Posix and XSI shell in more places, guarded by suitable tests. As long as the build system parallelizes well, I don't think there is too much cause for concern. For your own Makefile.am code, you can turn off warnings about nonportable constructs by adding -Wno-portability to the automake options. Cheers, Ralf
Re: Testing a new compiler with Automake simple tests
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 09:37:22PM CEST: At this point I can think only of two ways out: I'd go with the previous solution or use the *_OBJECTS variables. It's not likely that they change. As an aside: Ralf, do you think this variables are stable enough to be documented? If yes, do you think doing so would be worthwhile? They are fairly stable, but the conditionals logic does weird things which I'm not sure would never need changing, so I'd prefer not documenting them at this point. Cheers, Ralf
Re: GNU make or portable make?
Hi Tom, * Tom Tromey wrote on Wed, Aug 18, 2010 at 12:21:19AM CEST: The make part of the build parallelizes well, but the configure part does not. Yet. I think that is the big problem today. It is particularly noticeable in big trees like gcc or gdb. Both of whose build systems could use a bit of love, but yes, granted. GNU make could help solve this. See quagmire for a random stab at this idea. It isn't the most pleasant programming environment, but then neither is the m4+shell combination ;-). I'm sure there are other workable approaches as well. As much as I have sympathy with you for quagmire, I don't think it's the way I would go (wouldn't have said so had you not brought it up ;-) If one chooses to ditch the current system and start anew, I think it should both be simpler to program in, and it should have the right complexity for the edit-compile-test cycle even in very large trees, which so far only tup[1] has, but that again doesn't fulfill a lot of other needs. But again, I don't think autoconf is at the end of the road in enabling more Posix and XSI shell, nor have we seriously tried parallelism there yet (but now we have experience from Autotest). Cheers, Ralf [1] http://article.gmane.org/gmane.comp.gnu.make.general/7667
Re: [PATCH] Don't hide the table of contents
Hi Bruno, * Bruno Haible wrote on Sun, Aug 15, 2010 at 04:40:36PM CEST: Don't hide the table of contents. * doc/automake.texi: Move the table of contents to the beginning. Good one! Thanks, also for the explanations. Since the patch doesn't cause HTML node names to change nor other things to be reordered in any way, I'm adding this patch to the maint branch (maint is the maintenance branch for the active branches; see HACKING for more information about the active branching policy for Automake). Cheers, Ralf
Re: [PATCH] Optimize compile script on MSYS.
Hi Peter, [ output reordered to print new vs old ] * Peter Rosin wrote on Mon, Aug 16, 2010 at 01:59:13PM CEST: time for file in `./filenames 20 / .cc`; do ./compile cl $file; done real0m9.781s real0m9.875s time for file in `./filenames 20 / .cpp`; do ./compile cl $file; done real0m5.547s real0m9.906s time ./compile cl `./filenames 20 / .cc` real0m5.218s real0m5.187s time ./compile cl `./filenames 20 / .cpp` real0m0.734s real0m5.156s That's terrible. I mean, we are looking at more than 1000% overhead from the compile script in some cases. :-/ To conclude, this shaves off 4-5 seconds when compiling 20 files with absolute file names on MSYS. The cost when the new code isn't needed seems negligible in comparison. This means that we should still recommend the .cpp extension I guess. Or try `-TP ' or `-TC ' in preference to `-Tp' and `-Tc' since that means less translation, unless the switches provoke false positives or so. That said, don't expect too much from this as using absolute file names is not really the common case... But with -I and -L absolute names are common. Luckily, in typical cases compilation happens a lot more often than linking. We might want to pass $build system information from configure to 'compile' in order to avoid the uname fork. I meant to wait with this for a moment in which we'd need to start passing information in order to support more compilers in 'compile' anyway, not so sure any more now. Another idea would be to try to do file name translation manually in XSI shell; I'm not sure if it could be done without forking, nor whether we have all the information to do it correctly though. Subject: [PATCH] Optimize compile script on MSYS. * lib/compile (func_file_conv): Add new argument 'lazy' which takes an optional list of conversion types where the requested conversion isn't needed. (func_cl_wrapper): Take advantage of the above for cases where MSYS is doing the conversion for us. Suggested by Ralf Wildenhues. OK, thanks! --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,15 @@ 2010-08-16 Peter Rosin p...@... + Optimize compile script on MSYS. + * lib/compile (func_file_conv): Add new argument 'lazy' which + takes an optional list of conversion types where the requested + conversion isn't needed. + (func_cl_wrapper): Take advantage of the above for cases where + MSYS is doing the conversion for us. + Suggested by Ralf Wildenhues. + +2010-08-16 Peter Rosin p...@... + I tend to eliminate duplicate initial ChangeLog entry lines in successive entries, but I don't mind much either way, so do as is convenient for you. Note that the git-merge-changelog driver may currently re-introduce such lines when rebasing, that's an open TODO item there. Cheers, Ralf
Re: [PATCH] Don't hide the table of contents
Hi Bruno, * Bruno Haible wrote on Sun, Aug 15, 2010 at 04:40:36PM CEST: Don't hide the table of contents. * doc/automake.texi: Move the table of contents to the beginning. Good one! Thanks, also for the explanations. Since the patch doesn't cause HTML node names to change nor other things to be reordered in any way, I'm adding this patch to the maint branch (maint is the maintenance branch for the active branches; see HACKING for more information about the active branching policy for Automake). Cheers, Ralf
Re: Makefile to Makefile.am
Hello,
* Paul Smith wrote on Mon, Aug 16, 2010 at 04:33:46AM CEST:
On Sun, 2010-08-15 at 23:32 +0200, Ralf Wildenhues wrote:
# old fashioned suffix rule, portable
.xcf.bmp:
$(GIMP) -i -b '(xcf-bmp $ $@)' -b '(gimp-quit 0)'
Hey, maybe Automake hackers can riff off this thread in time for
the next release... (or, Would you like me to submit a patch?).
Yes, with a general example, please.
Note this is not enough: you also have to add these as prerequisites of
the .SUFFIXES target.
Not in a Makefile.am file, if each of the suffixes matches \.[^.]\{1,\}$
(this is an automake feature).
Cheers,
Ralf
Re: Recursive `make recheck'
Hello unnamed user[1], * autom...@raphael.poss.name wrote on Mon, Aug 16, 2010 at 02:47:07PM CEST: is it possible to add additional recursive targets? I'd like to get `recheck', `check-html' and `recheck-html' to work recursively. right now, that is only possible by manually coding the recursion yourself, for which you could copy code which automake generates for its recursive rules. Fixing that is a TODO item I hope to address in the near future: http://thread.gmane.org/gmane.comp.sysutils.automake.general/11890 Still, the code Automake currently generates for the recheck, check-html, and recheck-html targets only works well if all the Makefile.am files you have testsuites in are leafs; i.e., they should not themselves contain SUBDIRS. Otherwise, the local rules need to be renamed with 's/$/-am/'. Cheers, Ralf [1] we prefer people with names around here. Pseudonyms are fine if you deem that necessary, but my memory works much better when it can associate a real name with a topic. Thanks.
Re: Makefile to Makefile.am
* Thien-Thi Nguyen wrote on Sun, Aug 15, 2010 at 07:02:21PM CEST: Probably Automake manual (and its readers) could benefit from changing the mysterious: We do not discuss pattern rules here because they are not portable, but they can be convenient in packages that assume GNU `make'. to something like: Although pattern rules are not portable, they can be convenient in packages that assume GNU `make'. the pattern rule is used to match the stem of a filename, you can use the old fashioned suffix rule (pxref here) instead. For example: # pattern rule, not portable %.bmp : %.xcf $(GIMP) -i -b '(xcf-bmp $ $@)' -b '(gimp-quit 0)' # old fashioned suffix rule, portable .xcf.bmp: $(GIMP) -i -b '(xcf-bmp $ $@)' -b '(gimp-quit 0)' Hey, maybe Automake hackers can riff off this thread in time for the next release... (or, Would you like me to submit a patch?). Yes, with a general example, please. Thanks! Ralf
Re: Intermittent test failures
Hello again, * Ralf Wildenhues wrote on Sat, Jul 31, 2010 at 02:11:59PM CEST: * Ludovic Courtès wrote on Tue, Jul 27, 2010 at 11:08:39AM CEST: FYI the Automake test suite currently fails on Hydra. The build at http://hydra.nixos.org/build/502179 has 5 failures; the one at http://hydra.nixos.org/build/502171 has 2 failures, etc. thanks again for the report. Can you please check with the system administrator to find out whether the system has 1s granularity on time stamps or higher? ls -l --full-time in some directory on the same partition should hopefully answer that, if coreutils is not borked. And if better, we need to find out whether perl supports subsecond granularity and if that is true, whether Automake may have a bug in not getting/using that information correctly. If the file system granularity is 1s, then, the next steps are either: - making sure between start of configure and start of config.status at least 1s has passed (i.e., either reinstate the sleep in the sanity test or start a background sleep and check that before starting config.status) I now have a patch for the issue introduced in Automake git master with http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3643/ where the sanity check was changed to not sleep for a second by default any more. The patch is below. It would be nice if you could test it and report back. Or, if you prefer, I can apply and we see how build daemons react. There might still be a better solution to this issue without sleeping at all in more cases; I'm not totally convinced the time stamp handling in autotools is bugfree. Also, we could still exploit nonportable means to find out whether configure is more than a second old. OTOH some of the test failures were due to other autotools-generated files being just created, so we'd have to somehow optimistically test for them, too ... AFAICS this is the only regression in git master Automake over 1.11.1, so with this fixed, master should be in releasable state again (modulo other features we'd like to see in 1.12, of course). :-) Cheers, Ralf Fix timestamp issues by ensuring configure takes at least a second. * m4/sanity.m4 (AM_SANITY_CHECK): If we didn't sleep here, start a sleep in the background and wait for it to finish before creating config.status, hopefully fixing all spurious testsuite failures involving botched time stamps. * NEWS: Update. Reports by Ludovic Courtès, Peter Breitenlohner, and others. diff --git a/NEWS b/NEWS index 19e4548..0032c75 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,12 @@ New in 1.11a: - The `compile' script now converts some options for MSVC for a better user experience. + - Automake's early configure-time sanity check now tries to avoid sleeping +for a second, which slowed down cached configure runs noticeably. In that +case, it will check back at the end of the configure script to ensure that +at least one second has passed, to avoid time stamp issues with makefile +rules rerunning autotools programs. + Bugs fixed in 1.11a: - Lots of minor bugfixes. diff --git a/m4/sanity.m4 b/m4/sanity.m4 index db87c8b..94e1e51 100644 --- a/m4/sanity.m4 +++ b/m4/sanity.m4 @@ -1,13 +1,13 @@ # Check to make sure that the build environment is sane.-*- Autoconf -*- -# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008, 2009 +# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008, 2009, 2010 # Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. -# serial 6 +# serial 7 # AM_SANITY_CHECK # --- @@ -32,14 +32,14 @@ esac # (eg FreeBSD returns the mod time of the symlink's containing # directory). if ( + am_has_slept=no for am_try in 1 2; do - echo timestamp conftest.file + echo timestamp, slept: $am_has_slept conftest.file set X `ls -Lt $srcdir/configure conftest.file 2 /dev/null` if test $[*] = X; then # -L didn't work. set X `ls -t $srcdir/configure conftest.file` fi - rm -f conftest.file if test $[*] != X $srcdir/configure conftest.file \ test $[*] != X conftest.file $srcdir/configure; then @@ -55,6 +55,7 @@ if ( fi # Just in case. sleep 1 + am_has_slept=yes done test $[2] = conftest.file ) @@ -65,4 +66,19 @@ else AC_MSG_ERROR([newly created file is older than distributed files! Check your system clock]) fi -AC_MSG_RESULT(yes)]) +AC_MSG_RESULT(yes) +# If we didn't sleep, we still need to ensure time stamps of config.status and +# generated files are strictly newer. +am_sleep_pid= +if grep 'slept: no' conftest.file /dev/null 21; then + ( sleep 1 ) + am_sleep_pid=$! + AC_CONFIG_COMMANDS_PRE( +[if test -n $am_sleep_pid; then + AC_MSG_CHECKING
Re: Intermittent test failures
Hello again, * Ralf Wildenhues wrote on Sat, Jul 31, 2010 at 02:11:59PM CEST: * Ludovic Courtès wrote on Tue, Jul 27, 2010 at 11:08:39AM CEST: FYI the Automake test suite currently fails on Hydra. The build at http://hydra.nixos.org/build/502179 has 5 failures; the one at http://hydra.nixos.org/build/502171 has 2 failures, etc. thanks again for the report. Can you please check with the system administrator to find out whether the system has 1s granularity on time stamps or higher? ls -l --full-time in some directory on the same partition should hopefully answer that, if coreutils is not borked. And if better, we need to find out whether perl supports subsecond granularity and if that is true, whether Automake may have a bug in not getting/using that information correctly. If the file system granularity is 1s, then, the next steps are either: - making sure between start of configure and start of config.status at least 1s has passed (i.e., either reinstate the sleep in the sanity test or start a background sleep and check that before starting config.status) I now have a patch for the issue introduced in Automake git master with http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3643/ where the sanity check was changed to not sleep for a second by default any more. The patch is below. It would be nice if you could test it and report back. Or, if you prefer, I can apply and we see how build daemons react. There might still be a better solution to this issue without sleeping at all in more cases; I'm not totally convinced the time stamp handling in autotools is bugfree. Also, we could still exploit nonportable means to find out whether configure is more than a second old. OTOH some of the test failures were due to other autotools-generated files being just created, so we'd have to somehow optimistically test for them, too ... AFAICS this is the only regression in git master Automake over 1.11.1, so with this fixed, master should be in releasable state again (modulo other features we'd like to see in 1.12, of course). :-) Cheers, Ralf Fix timestamp issues by ensuring configure takes at least a second. * m4/sanity.m4 (AM_SANITY_CHECK): If we didn't sleep here, start a sleep in the background and wait for it to finish before creating config.status, hopefully fixing all spurious testsuite failures involving botched time stamps. * NEWS: Update. Reports by Ludovic Courtès, Peter Breitenlohner, and others. diff --git a/NEWS b/NEWS index 19e4548..0032c75 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,12 @@ New in 1.11a: - The `compile' script now converts some options for MSVC for a better user experience. + - Automake's early configure-time sanity check now tries to avoid sleeping +for a second, which slowed down cached configure runs noticeably. In that +case, it will check back at the end of the configure script to ensure that +at least one second has passed, to avoid time stamp issues with makefile +rules rerunning autotools programs. + Bugs fixed in 1.11a: - Lots of minor bugfixes. diff --git a/m4/sanity.m4 b/m4/sanity.m4 index db87c8b..94e1e51 100644 --- a/m4/sanity.m4 +++ b/m4/sanity.m4 @@ -1,13 +1,13 @@ # Check to make sure that the build environment is sane.-*- Autoconf -*- -# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008, 2009 +# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008, 2009, 2010 # Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. -# serial 6 +# serial 7 # AM_SANITY_CHECK # --- @@ -32,14 +32,14 @@ esac # (eg FreeBSD returns the mod time of the symlink's containing # directory). if ( + am_has_slept=no for am_try in 1 2; do - echo timestamp conftest.file + echo timestamp, slept: $am_has_slept conftest.file set X `ls -Lt $srcdir/configure conftest.file 2 /dev/null` if test $[*] = X; then # -L didn't work. set X `ls -t $srcdir/configure conftest.file` fi - rm -f conftest.file if test $[*] != X $srcdir/configure conftest.file \ test $[*] != X conftest.file $srcdir/configure; then @@ -55,6 +55,7 @@ if ( fi # Just in case. sleep 1 + am_has_slept=yes done test $[2] = conftest.file ) @@ -65,4 +66,19 @@ else AC_MSG_ERROR([newly created file is older than distributed files! Check your system clock]) fi -AC_MSG_RESULT(yes)]) +AC_MSG_RESULT(yes) +# If we didn't sleep, we still need to ensure time stamps of config.status and +# generated files are strictly newer. +am_sleep_pid= +if grep 'slept: no' conftest.file /dev/null 21; then + ( sleep 1 ) + am_sleep_pid=$! + AC_CONFIG_COMMANDS_PRE( +[if test -n $am_sleep_pid; then + AC_MSG_CHECKING
Re: Makefile to Makefile.am
Hello, * samson.pierre wrote on Sat, Aug 14, 2010 at 04:01:15AM CEST: GIMP=gimp RM=rm -rfv BMP=bat.bmp beaver.bmp brown_bear.bmp cow.bmp coypu.bmp dromedary.bmp eel.bmp elephant.bmp giraffe.bmp golden_eagle.bmp great_white_shark.bmp hammerhead_shark.bmp human.bmp hyena.bmp jackal.bmp jellyfish.bmp lion.bmp lynx.bmp moose.bmp oryx.bmp otter.bmp scorpion.bmp spider.bmp squirrel.bmp zebra.bmp all: $(BMP) %.bmp: %.xcf $(GIMP) -i -b '(xcf-bmp $ $@)' -b '(gimp-quit 0)' clean: $(RM) *.bmp --- Can you write a Makefile.am which can help to generate a Makefile nearly the same as this Makefile? Yes. You simply 'mv Makefile Makefile.am' and replace 'all' with 'all-local' and 'clean' with 'clean-local'. That's it! Of course you still need to write a configure.ac file and so on, but I guess you can find yourself though there by reading through the Hello World example in the introduction of the manual: http://www.gnu.org/software/automake/manual/html_node/Autotools-Introduction.html Cheers, Ralf
better support for profiling/feedback optimization/coverage
Hello automakers, Luca suggested Automake could be more helpful with profiling, profile-guided optimization, coverage measurement. So let's start evaluating the current situation, to get a bit better overview. For the packages using C or C++ which I work on, it suffices to ./configure CFLAGS='-fprofile-generate -O2 ...' make all check # assuming this will produce typical exercise make clean ./configure CFLAGS='-fprofile-use -O2 ...' make all install and at least with fairly recent GCC versions, that works in VPATH builds, too. Similar for --coverage etc. So, I guess my question is: do you have more complicated setups or issues to work around where Automake could help, or where the information that automake already gets may take away some work from you? Other good suggestions? Thanks! Ralf
Re: [PATCH] Support more C++ extensions for MSVC in the compile script.
Hi Peter, * Peter Rosin wrote on Fri, Aug 13, 2010 at 03:37:59PM CEST: This is one of the last bits of functionality from the (dwindling) pr-msvc-support branch in Libtool (the remaining bit is triggering the ar-lib script with a new macro and some things related to that). Cool. MSVC only recognizes .c and .cpp as source files, if you say e.g. foo.cc, it will treat it as an object file. Many projects do not use .cpp for its C++ files, so this patch will make it work for a bunch of more projects. I have not added .C to the list of C++ extensions as Windows typically has a case insensitive file system, and then you don't know if the user meant C or C++... Good point. Users will have to cope anyway. Ok for the msvc branch? Ok with nits below addressed. Thanks! Ralf +2010-08-13 Peter Rosin p...@lysator.liu.se + + Support more C++ extensions for MSVC in the compile script. s/extensions/file / ? IMHO that would make it a bit clearer. + * lib/compile (func_cl_wrapper): MSVC only recognizes the .cpp + extension as C++, unless it's given a hint. So hint about + .cc, .cxx, c++ and C++. Also do path conversion on .c, .cpp + and .lib files. See below for a question about this. + * lib/compile3.test: Test the C++ hinting. --- a/lib/compile +++ b/lib/compile @@ -129,6 +129,16 @@ func_cl_wrapper () eat=1 linker_opts=$linker_opts $2 ;; Please add a case -*) set x $@ $1 shift ;; here and simplify the following matches accordingly. + [!-]*.cc | [!-]*.cxx | [!-]*.[cC]++) What about *.CC and *.CXX? + func_file_conv $1 + set x $@ -Tp$file + shift + ;; + [!-]*.c | [!-]*.cpp | [!-]*.lib | [!-]*.LIB | [!-]*.Lib) + func_file_conv $1 What about *.CPP? Why do you convert here? Seems to me that since the files stand alone, MSYS conversion would kick in, no? If this is about conversion on non-MSYS systems, please state so in the log entry. Thanks. Actually, there is an efficiency question in there: we know when exactly name conversion happens on MSYS, namely when the name is a positional parameter on its own (and in a couple of other cases which I have all but forgotten again). In those cases, we could avoid doing manual conversion, thereby avoiding extra forks. One way this could be implemented would be to pass an extra argument $2 to func_file_conv that could be empty or -lazy or so, and in the function match against $file_conv$2 with cygwin-lazy same as cygwin but mingw-lazy a nop. If you think this is worthwhile, then I would accept such a change in a later patch, given some numbers that show an actual improvement. I can also write the patch if you do the measurement. (Trying to stick to the no optimization without measurement principle.) + set x $@ $file + shift + ;; *) set x $@ $1 shift
Re: [PATCH] Improve support for non-default autotools in rebuild rules.
Hi Stefano, * Stefano Lattarini wrote on Thu, Aug 12, 2010 at 07:00:08PM CEST: Note that I have not yet run the whole testsuite on this change; I will if you tell me you're interested in the patch. I'm intrigued by the fact that there appears to be a bug in the current implementation. I agree with you in finding the patch not exactly clean. ;-) Why are you not suggesting AM_MISSING_PROG([AUTOM4TE], [autom4te])? I guess I don't really see why searching for autom4te is somehow a better a idea than finding out which autom4te autoconf actually uses: that is, either $AUTOM4TE if set, or the thing that was compiled in, which at least is guaranteed to match the Autoconf version which autoconf comes from. And from a user standpoint, I'm sure some would be surprised to see their configure script search for a behind-the-scenes tool they never knew was being used at all. Of course, with AM_MISSING_PROG there is still the problem that I think neither of autoconf, autoheader, ..., aclocal, automake are prepared for a return value of 63 from autom4te, which should probably let them return 63 as well. Haven't checked though. Cheers, Ralf
Re: transform2.test failure on Cygwin: replacing an executable with a script
* Peter Rosin wrote on Fri, Aug 13, 2010 at 03:55:54PM CEST: Den 2010-08-07 17:56 skrev Ralf Wildenhues: install bla.exe .../inst/bin/foo.exe install script.sh .../inst/bin/foo and the second one fails (to overwrite the foo.exe). Does anybody happen to know if this is due to a change in Cygwin semantics? This sounds like a change in Cygwin exe-magic that I unfortunately fail to find any reference to. http://thread.gmane.org/gmane.os.cygwin/119380? I haven't read through it yet. Cheers, Ralf
translation of command line arguments (was: New auxiliary archive script)
* Peter Rosin wrote on Fri, Aug 13, 2010 at 11:38:43AM CEST: Den 2010-08-12 19:55 skrev Ralf Wildenhues: Same with 'compile' by the way. If -O3 is spelt differently for cl, then I think translating that is a good idea. I think we should keep such translation to a bare minimum. The chance of options clashing is just too high, and that will cause end user confusion. *snip more good points* Also, there aren't going to be perfect matches for most options anyway. It's just a losing game. And to further add to the burden, the translation is likely to be dependent on compiler version. All good points. Thanks. On the other hand, this means that better support for cl means adjusting a number of macros from Autoconf, Gnulib, and maybe Automake as well. For example, what about dependency tracking? Does the current code enable msvcmsys or msvisualcpp depmode if --enable-dependency-tracking is specified? Your MSVC status post on libtool-patches doesn't tell. -g does not mean anything to cl, which is fortunate. Unfortunately it only prints a warning on stderr, so the autoconf test thinks it's ok to use it which means that you get that warning all over the place unless you help the -g test or override CFLAGS manually. cl : Command line warning D9002 : ignoring unknown option '-g' There is autoconf code to look for output on stderr when testing if -g is a viable option, but unfortunately cl always outputs a logo on stderr, unless you feed it -nologo, so the autoconf test only works if you set CC=cl -nologo. Given that the stderr code seems to have been added to autoconf in response to a cl report, that code seems rather broken... Hmpf. Not sure what to do; for the moment an addition to install.texi to specify CC=cl -nologo CFLAGS= would probably be prudent. Cheers, Ralf
Re: [PATCH] Improve support for non-default autotools in rebuild rules.
* Stefano Lattarini wrote on Fri, Aug 13, 2010 at 07:38:13PM CEST: Hi Ralf. Sorry you missed my last drop this message... I didn't. I just hoped the post might be helpful anyway. Just ignore it if it distracts you. At Friday 13 August 2010, Ralf Wildenhues wrote: Why are you not suggesting AM_MISSING_PROG([AUTOM4TE], [autom4te])? Bacause `missing 'recognizes autom4te as special, and tries to work around it if it's broken or not avaiable; but I do not want this workaround to kick in when $AUTOM4TE is called by e.g. aclocal, since aclocal needs a real autom4te run anyway. Why? We don't fail either if aclocal is completely absent. Better to have a flat-out failure in this case. Alas, something similar holds for autoconf-called-by-automake too, so the patch is bounded to become still messier... I guess I fail to understand why the 63 rule should apply to one situation but not the other. I guess I don't really see why searching for autom4te is somehow a better a idea than finding out which autom4te autoconf actually uses: that is, either $AUTOM4TE if set, or the thing that was compiled in, which at least is guaranteed to match the Autoconf version which autoconf comes from. Hmm... this is right, and I started to realize it by myself also... Probably something likethis would be enough: test -z $AUTOM4TE AUTOM4TE=autom4te AC_SUBST([AUTOM4TE]) I'm not sure that is right, because configure doesn't know what's stored as default in automake, autoconf, aclocal etc., so this might not be what you wanted. Let's postpone further discussion until I post the updated patch, ok? Sure. Thanks, Ralf
Re: [PATCH] Improve support for non-default autotools in rebuild rules.
* Stefano Lattarini wrote on Sat, Aug 14, 2010 at 01:18:14AM CEST:
At Friday 13 August 2010, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Fri, Aug 13, 2010 at 07:38:13PM CEST:
At Friday 13 August 2010, Ralf Wildenhues wrote:
Why are you not suggesting AM_MISSING_PROG([AUTOM4TE],
[autom4te])?
Bacause `missing 'recognizes autom4te as special, and tries to
work around it if it's broken or not avaiable; but I do not want
this workaround to kick in when $AUTOM4TE is called by e.g.
aclocal, since aclocal needs a real autom4te run anyway.
Why? We don't fail either if aclocal is completely absent.
Yes, and this is justified IMO. But if aclocal proper is ever called,
it needs a working autom4te to get traces from e.g. configure.ac, and
the workaround provided by `missing --run autom4te' is not enough
in such a case
Are you describing here how the current code behaves or how you think it
should behave?
(JFTR, `missing' is IMHO useful, but it's also a mixed blessing).
Sure it has downsides. It allows the end user to build some piece of
code even if the tarball/vcs checkout has messed up time stamps and the
regeneration tools are missing. With downsides for the developer who
then has to take more care while working on the code.
Probably something likethis would be enough:
test -z $AUTOM4TE AUTOM4TE=autom4te
AC_SUBST([AUTOM4TE])
I'm not sure that is right, because configure doesn't know what's
stored as default in automake, autoconf, aclocal etc.,
Why not? AM_INIT_AUTOMAKE ensures at least a `missing' wrapper for
each of them, doesn't it? But probably I'm not undrstanding your
objection... clarifications are welcome.
You can configure Autoconf with, say, --program-prefix=-2.67, and that
will cause autoconf to contain code like
AUTOM4TE=${AUTOM4TE-autom4te-2.67}
Now, when $AUTOM4TE is unset at the time package foo is configured, and
foo has the code you suggest above, then that AUTOM4TE=autom4te will
break a perfectly working setup.
Cheers,
Ralf
Re: RE : call for help/crazy idea: nmake support
I would like to thank everyone who provided input on this topic. It certainly helps when considering where to go. One conclusion from this is that we should get Peter's MSVC support finished and completed for Automake 1.12 and the next Libtool release. I wasn't aware that there are more MSVC-related build system tools which one could target. I'm still not sure whether the idea to produce support for some of them should be buried completely, but I for one won't be pursuing it in the nearer future. If somebody else feels scratching that it however ... And of course I would be delighted if some of you provided fixes for pkg-config and whetever else is needed to make building for this setup work better. Thanks, Ralf
Re: New auxiliary archive script
* Peter Rosin wrote on Thu, Aug 12, 2010 at 01:05:09PM CEST: Den 2010-08-12 05:29 skrev Ralf Wildenhues: * Peter Rosin wrote on Wed, Aug 11, 2010 at 04:12:10PM CEST: Oh... oh! That means that AM_PROG_CC_WRAPPER and AM_PROG_CC_C_O should trigger 'compile' for completely different reasons, and that a projects should use AM_PROG_CC_WRAPPER to trigger support for MSVC (et al) and AM_PROG_CC_C_O should trigger it when the resulting makefiles require a compiler that supports -c -o. Yes. Automake should be able to answer the latter question given its input, right? Yes. IOW, is AM_PROG_CC_C_O really needed? Not in the documentation recommending how to enable msvc support. But Automake must continue providing it for backwards compatibility to user configure.ac scripts which use it. And ATM, with us currently supporting only MSVC through 'compile', it is sufficient if both macros internally do the same thing for now. The important bit is to document the intention of both macros as different. (I understand that it might not be easy to get it right, and that it might just be a whole lot easier if the author has to add AM_PROG_CC_C_O whenever it is needed) What I'm saying is that maybe AM_PROG_CC_C_O and AM_PROG_CC_WRAPPER shouldn't be synonyms. I agree if we replace the last words with shouldn't be documented to be synonyms. That's trivially (and fairly safely) fixed though. I mean, is there some real obstacle to also supporting 'link -lib'? No, there's no real obstacle. The script could recognize 'link -lib' as a special combination and treat the pair as PROGRAM. Or always pass on any '-lib' option to PROGRAM w/o trying to interpret it further. That might be a good addition, since there might be other interesting options to pass through, and those could then be added to the exception list the same way, e.g. -LTCG (or -ltcg, case don't matter, link time code generation), -MACHINE and -SUBSYSTEM. But maybe those options can be added after cru as is by setting ARFLAGS? Yes, I suppose it is prudent for 'ar-lib' to pass through (or translate) all those flags which users might want to set and which are not problematic wrt. mis-parsing. You already posted a patch for this. Same with 'compile' by the way. If -O3 is spelt differently for cl, then I think translating that is a good idea. I don't recall which flags actually needed translation; if that actually includes -g or -O2 then we have a problem, because AC_PROG_CC will test that before we get a chance to chime in. Cheers, Ralf
Re: [PATCH] Enable the use of link -lib as the wrapped archiver.
Hi Peter, * Peter Rosin wrote on Thu, Aug 12, 2010 at 06:03:03PM CEST: From 8c406f64b66aedee8359ddf1383e087faa2ba233 Mon Sep 17 00:00:00 2001 From: Peter Rosin p...@lysator.liu.se Date: Thu, 12 Aug 2010 18:01:18 +0200 Subject: [PATCH] Enable the use of link -lib as the wrapped archiver. * lib/ar-lib: Enable the use of link -lib as the wrapped archiver, as well as allowing some other options to be passed through to the wrapped archiver. * tests/ar-lib.test: Test the above. Signed-off-by: Peter Rosin p...@lysator.liu.se This is ok for the msvc branch (which I just pushed to make it public). Thanks. I'd like to ask you to commit all approved msvc patches initially to the msvc branch, unless otherwise noted. You can also at any time you like merge the msvc branch to the master branch. Committing to msvc first allows us to still decide whether and when the branch should be merged to branch-1.11 (or maint, for that matter) as well, without dragging in the rest of master. If there will be commits that I think are good, but maybe not suitable for branch-1.11, we may want to split msvc in two branches, say with a new msvc-compat branch which then only holds those patches that are good for backporting. In that case merging from msvc-compat to msvc and from either to master is ok to do at any time. The general idea is that patches only involving 'ar-lib' and 'compile' in their public API are pretty much always good for 1.11 as well, but new API should go to 1.12 only. Cheers, Ralf
Re: options and automake version
* Jason Kraftcheck wrote on Thu, Aug 12, 2010 at 05:25:10PM CEST: I would like to enable some of the options new to version 1.11 of automake (color-tests, silent-rules, parallel-tests.) However, many of the people I work with are still using version 1.10. I had hoped that 1.10 would just ignore unrecognized options, as the options I wanted to add are not essential to the build process. Unfortunately, automake fails when it encounters unrecognized options. Is there some trick I could use to conditionally add the options if they are supported? Unfortunately, we don't have a macro yet to ask automake whether some version is supported; that is on the TODO list; see here for some discussion: http://thread.gmane.org/gmane.comp.sysutils.automake.general/10933 For features introduced with 1.11, you should be able to workaround like this: m4_ifdef([AM_SILENT_RULES], [AM_INIT_AUTOMAKE([silent-rules parallel-tests color-test ...])], [AM_INIT_AUTOMAKE([...])]) Cheers, Ralf
Re: [PATCH] Work around a nasty bug of Solaris make
* Stefano Lattarini wrote on Wed, Aug 11, 2010 at 06:47:01PM CEST: At Friday 06 August 2010, Ralf Wildenhues wrote: From 92020702ac9b8cde2ecfa248b5d34795d7209e44 Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Fri, 6 Aug 2010 00:40:55 +0200 Subject: [PATCH] Work around a nasty bug (segfault) of Solaris make. * lib/am/check.am (recheck, recheck-html): Trim trailing spaces from $list, to avoid triggering a nasty bug (potential segfault) on Solaris make. OK for maint. Ouch! I see now that I pushed it to master only... it's OK if I apply it to maint too, then merge back to master and fix the possible fallouts (e.g. slighty botched ChangeLog entry or merge conflicts)? Sure. I wouldn't even bother too much with ChangeLog entries. Thanks! Ralf
Re: New auxiliary archive script
* Peter Rosin wrote on Wed, Aug 11, 2010 at 04:12:10PM CEST: One thing to consider is that the compile script is triggered by chance for MSVC. It is just a lucky coincidence that MSVC doesn't support -c -o, so that the compile script can add that support and then tag on the other needed crap. I think the Intel C compiler on Windows has a similar option set as MSVC, so it can probably be handled in much the same way. But if the Window PGI compiler needs a wrapper, I don't think it will be triggered by the current implementation of AM_PROG_CC_C_O. That's a problem, but not a big one. We can always add more tests to this macro that trigger a wrapper, as long as C compilers on unixes are not affected. Adding a better-named synonym macro is prudent, too, such as maybe AM_PROG_CC_WRAPPER. If people didn't like having 'compile' in their tarballs, Well, people disliked having their compiler go through another wrapper. (Add to this that it could happen sometimes even though it was not necessary.) there can be only one reason, -c -o is supported by all the compilers they need. In which case they have not previously needed MSVC, or have that covered by other means, i.e. a separate build system. Maybe more projects will move over to using an autotooled build system for MSVC, but that is far from certain. Well, I know a few Linux kernel module packages are built with automake. I can understand why they wouldn't be interested in MSVC support, and would see additional code to that end as a waste. For one thing, it's going to be slower than separately maintained MSVC project files. But I hate separate build systems -- it is bad enough to maintain one for a project -- and I (obviously) want to do configure; make for MSVC. Agreed. But others are obviously entitled to their own opinion and *I* am not going to force 'compile' and 'ar-lib' on them if loads of users don't want them. Please don't get me wrong, this isn't about devaluing your contribution at all. Rather, it is about flexibility that users may want (or even need) vs. ease of use or ease of transition. Anyway, I'm too biased to vote on this issue. Understood. It all comes down to if we want (1) or (2). I obviously find (2) very appealing but as I stated above, I don't think this is my call. Well, let's reformulate the question then: while (2) is appealing, (1) seems conceptually cleaner. Would you mind having to adjust packages for solution (1)? I imagine most users wouldn't, given that the prospect is going from two build systems to one with a two-line change in configure.ac and a re-bootstrap. And possibly other adjustments they'd need to make anyway (see also the thread referenced below). So, unless you object strongly, let's go with (1). Hasn't autotools lost quite a bit of market share to CMake because it hasn't supported MSVC? Probably, but market share is not an issue I think we should take into account when deciding *how* to implement something, rather than deciding *what* do work on. On the other hand, CMake produces MSVC project files, maybe that is seen as a killer feature? Well, I inquired about this recently on the automake list: http://thread.gmane.org/gmane.comp.sysutils.automake.general/11885 So far most feedback seems to be that they would likely be happy when this is implemented! :-) Finally, does your wrapper work with 'link -lib' too? No it doesn't, ar-lib then thinks only 'link' is the program and then tries to interpret '-lib' as ar actions - boom. That's trivially (and fairly safely) fixed though. I mean, is there some real obstacle to also supporting 'link -lib'? Can we think of a situation in which it may be useful to have the configure.ac author (rather than the user invoking configure) modify the set of tools we try for $AR? Then we should leave a macro argument IF-FAILS for that purpose, defaulting to error. That seems like overkill to me, why shouldn't such a change be done in upstreams libtool from the start? Do you worry about configure.ac authors having to wait for a new libtool version to be released? No. In fact, I think we'll be able to provide releases for both versions in timely-enough manners so that this shouldn't be an issue. Then, when we have all these sorted out: would you be willing to write testsuite additions to cover as many of the semantics as possible (warn about misordering, recommend AM_PROG_AR, use it without or with Libtool, etc)? I will certainly try. Thanks. If you need help or would like to share the load please feel free to say so. You can also always post patch versions you have. (But please do start a new thread.) FWIW, for users of Libtool that don't use Automake, it should still be possible to use the wrappers by using only AM_PROG_CC_C_O AM_PROG_AR and letting aclocal install the needed macro definitions. For this to keep working it would be good to ensure that these macros don't require AM_INIT_AUTOMAKE
Re: New auxiliary archive script
* Peter Rosin wrote on Tue, Aug 10, 2010 at 09:01:29AM CEST: 'wrappar' did cross my mind, but that just looks like a funny accent :-) Yes, that one is funny indeed, and another almost-palindrome. Den 2010-08-09 21:39 skrev Ralf Wildenhues: Further I'm fixing the archive and the compile script to use ! not ^ for shell pattern negation, and using $me also in the --help output. I tested with $me in the --help output but didn't get it to work so I removed it. But your version works. Sigh... The difference between a quoted and an unquoted here-document: cat eof $HOME sweet home. eof cat \eof $HOME sweet home. eof Should there be a verbose/debug mode in which the scripts print the command(s) that they invoke; or even do this by default? This could help debug user failures in the future. Any extra output from ar-lib lib t foo.lib would break some uses, unless it was on stderr of course. Other actions are less critical, but you can always bash -x it, the script is smallish and output isn't hard to parse. But a debug mode would be nice all the same... OK. This is not too pressing. Wrt. the AM_PROG_AR implementation, __oline__ is a real nono, as it causes spurious diffs in generated configure scripts. I'll propose an updated version. Oh, didn't know that. I look forward to it, since I reused some of the code for the @FILE feature check for archivers needed in libtool. I didn't know either, until GCC developers complained enough about their spurious configure diffs. And more, __oline__ was invented only because of buggy shells not coping correctly with $LINENO. Luckily the uses here are not a problem with nowadays shells. OK, so here's what I got now, rewriting the macro to log better. Two issues: For one, it now uses AC_TRY_EVAL which is deprecated, but I can't see a better Autoconf API to use ATM. More importantly, I think it remains to decide the intended use semantics, not just for 'ar-lib' but even more importantly also for 'compile': 1) Do we want to allow/require the developer to decide I want to make my package suitable for building with MSVC? 2) Or do we even want MSVC support to be added onto existing packages by default? If (1), then currently, the required steps seem to be adding AM_PROG_CC_C_O AM_PROG_AR to configure.ac. This is probably the more flexible approach, but it means that packages need updating. Also, the naming of AM_PROG_CC_C_O is a bit suboptimal in that case, maybe we should introduce a new macro AM_PROG_CC_WRAP that is documented to wrap majorly incompatible compilers like w32; internally, it would for now just call AM_PROG_CC_C_O. (There is also the possibility to use yet another Automake option, but I'd prefer to avoid that.) If (2), then we could for example tack the ar test onto Autoconf's ranlib test: m4_define([AC_PROG_RANLIB], [AM_PROG_AR m4_defn([AC_PROG_RANLIB]) ]) This seems quite hacky, and might sit at odds with some developers, esp. for packages that can never run on w32 for unrelated reasons anyway. Also, I'm not yet sure what to do with 'compile' in that case. (Developers have complained a lot about suggesting AM_PROG_CC_C_O until we moved the warning to -Wportability.) Users that would like to write their configure.ac scripts to be portable to Automake with or without this code, should write something like this in case (1): # Use new macros if they are defined. m4_ifdef([AM_PROG_CC_WRAP], [AM_PROG_CC_WRAP], [AM_PROG_CC_C_O]) m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) and should ideally not have to change anything in the case of (2). Interaction with Libtool: With Libtool and in case (1), AM_PROG_AR should come before LT_INIT. Then we should put in AC_BEFOREs to warn about misordering. Also, we kind of lose the ability to detect within Libtool macros whether $AR was set by the user. This isn't a problem now, but I'm not so sure it cannot become one in the future. We'll see I guess. With (2), we could then AC_REQUIRE AM_PROG_AR from _LT_CMD_OLD_ARCHIVE if the former is defined (and keep the AC_CHECK_TOOLS([AR]) otherwise). Remember that Libtool should remain usable without Automake. Finally, does your wrapper work with 'link -lib' too? Can we think of a situation in which it may be useful to have the configure.ac author (rather than the user invoking configure) modify the set of tools we try for $AR? Then we should leave a macro argument IF-FAILS for that purpose, defaulting to error. Then, when we have all these sorted out: would you be willing to write testsuite additions to cover as many of the semantics as possible (warn about misordering, recommend AM_PROG_AR, use it without or with Libtool, etc)? Below is the meat of AM_PROG_AR that I have currently. Thanks, Ralf AC_CACHE_CHECK([the archiver ($AR) interface], [am_cv_ar_interface], [am_cv_ar_interface=ar AC_COMPILE_IFELSE([[int some_variable = 0;]], [am_ar_try='$AR cru libconftest.a conftest
Re: [PATCH] Minor improvements for tests `acloca*.test'.
* Stefano Lattarini wrote on Wed, Aug 11, 2010 at 01:28:44AM CEST: Being forced to rescan this patch some time after having written it, I must admit that the noise-to-improvement ratio is way too high. So OK, let's drop most of this patch. However, I'd like to retain a couple of changes more than the ones blessed by you here. WDYT about the trimmed-down attached patch? Still high, but OK for maint. Thanks, Ralf Tweak and/or extend some `acloca*.test' tests. * tests/aclocal8.test: Ensure verbose printing of captured output. * tests/aclocal.test: Likewise. Also, add trailing `:' command. * tests/acloca19.test: Likewise. * tests/aclocal5.test: Add trailing `:' command, and prefer `$me' over hard-coded test name. * tests/aclocal6.test: Likewise. * tests/aclocal18.test: Add trailing `:' command, and make some grepping slighty stricter. * tests/acloca14.test: Likewise. Also, prefer `diff' over `cmp', and add some cosmetic blank lines.
Re: No rule to make target in a BUILT_SOURCES, non-recursive, multi-directory project
Hi Jeff, * Daily, Jeff A wrote on Tue, Aug 10, 2010 at 08:54:53PM CEST: I am using subdir-objects and I have a single, top-level Makefile.am: #*snip* BUILT_SOURCES = lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = #*snip* If HAVE_PYTHON BUILT_SOURCES += foo/bar/wapi.c foo/bar/wapi.c: foo/bar/papi.h $(top_srcdir)/build-aux/wapi.py -rm -f foo/bar/wapi.c \ $(PYTHON) $(top_srcdir)/build-aux/wapi.py $ foo/bar/wapi.c libfoo_la_SOURCES += foo/bar/wapi.c endif #*snip* It turns out that $(PYTHON) is located by configure such that HAVE_PYTHON is true. When I configure and build from a subdirectory within my source tree e.g. mkdir bld; cd bld; ../configure the build fails because make is looking for the target ../foo/bar/wapi.c which doesn't exist, Which make version and implementation, which Automake version? Do you somehow ensure foo/bar exists in the build tree beforehand? Does the file foo/bar/papi.h exist in the source or in the build tree? The above works for me; but VPATH target lookup is tricky across make implementations, see 'info Autoconf VPATH and Make' and the last node referenced therein. Using $ in non-inference rules is not portable to non-GNU make. Cheers, Ralf
Re: No rule to make target in a BUILT_SOURCES, non-recursive, multi-directory project
* Daily, Jeff A wrote on Tue, Aug 10, 2010 at 09:45:43PM CEST: Which make version and implementation, Please answer this one as well.
Re: New auxiliary archive script
* Andrew W. Nosenko wrote on Sat, Aug 07, 2010 at 02:02:09PM CEST:
On Sat, Aug 7, 2010 at 09:03, Ralf Wildenhues wrote:
Darn, we need another name: 'archive' is likely too common when automake
is going to put all files with that name in the distribution of each
package using Automake. No need to send another patch, but any other
good suggestions that fit in with the existing scripts?
Suggestions appreciated.
am-archive ?
am-archive-helper ?
archive-helper is not bad, but a bit long. I don't like the 'am-'
prefixes much for the name, the script doesn't necessarily have to
have close ties to Automake.
* Gary V. Vaughan wrote on Sun, Aug 08, 2010 at 08:40:03AM CEST:
That's no different to the situation with 'compile'. I think 'archive'
is a perfectly good name as it is.
Well, the difference in situation is that 'compile' was introduced 11
years ago, when breaking compatibility was frequent; and that 'archive'
is both a verb and a noun, and being used as, well, a name for an
archive of stuff by people. Cf. gettext, for example.
* Peter Rosin wrote on Sat, Aug 07, 2010 at 06:10:54PM CEST:
I suggested arwrap, like ylwrap, but that message seems stuck somewhere...
Yes. I hope that the mails have all come through by now since the list
server downtime.
ar-lib is also fine by me.
Good. I have an ever so slight preference of that over arwrap, simply
because I cannot pronounce the latter. And we can re-interpret ar-lib
from archive wrapper for LIB to archiver for libraries if that helps
making it more general. ;-)
So, I'm picking the script addition part from your commit, adding it to
the msvc branch and merging to master for now:
+2010-08-06 Peter Rosin p...@lysator.liu.se
+
+ Add new auxiliary 'archive' script, wrapping Microsoft lib.
+ * lib/archive: New auxiliary script.
+ * lib/Makefile.am: Add above.
+ * tests/archive.test: New test.
+ * tests/Makefile.am: Add above.
+ * automake.in (@common_files): Distribute the 'archive' script.
+ * doc/automake.texi (Auxiliary Programs): Mention the new
+ 'archive' script.
+ (Optional): Mention 'archive' in AC_CONFIG_AUX_DIR.
omitting the doc parts that mention AM_PROG_AR, and rewriting this:
+ * NEWS: Update.
to be as below.
Further I'm fixing the archive and the compile script to use ! not ^ for
shell pattern negation, and using $me also in the --help output.
Should there be a verbose/debug mode in which the scripts print the
command(s) that they invoke; or even do this by default? This could
help debug user failures in the future.
Wrt. the AM_PROG_AR implementation, __oline__ is a real nono, as it
causes spurious diffs in generated configure scripts. I'll propose
an updated version.
Thanks,
Ralf
--- a/NEWS
+++ b/NEWS
@@ -6,10 +6,7 @@ New in 1.11.0a:
is obsoleted by `xz' and `dist-xz' due to upstream changes.
- The `compile' script now converts some options for MSVC for a better
-user experience.
-
- - New macro AM_PROG_AR that looks for an archiver and wraps it in the new
-'archive' auxiliary script if the found archiver is Microsoft lib.
+user experience. Similarly, the new `ar-lib' script wraps Microsoft lib.
Bugs fixed in 1.11.0a:
--- a/lib/archive
+++ b/lib/archive
@@ -47,7 +47,7 @@ func_file_conv ()
{
file=$1
case $file in
-/ | /[^/]*) # absolute file, and not a UNC file
+/ | /[!/]*) # absolute file, and not a UNC file
if test -z $file_conv; then
# lazily determine how to convert abs files
case `uname -s` in
--- a/lib/compile
+++ b/lib/compile
@@ -45,7 +45,7 @@ func_file_conv ()
{
file=$1
case $file in
-/ | /[^/]*) # absolute file, and not a UNC file
+/ | /[!/]*) # absolute file, and not a UNC file
if test -z $file_conv; then
# lazily determine how to convert abs files
case `uname -s` in
Fix maintainer-check failure; sync upstream files.
FWIW, I've synced config.guess, config.sub, and texinfo.tex from upstream, and fixed a maintainer-check failure as below, both patches for maint. Cheers, Ralf Fix maintainer-check failure. * tests/cond5.test: Quote sleep argument, this isn't about time stamp differences. diff --git a/tests/cond5.test b/tests/cond5.test index 88e2e42..50101a6 100755 --- a/tests/cond5.test +++ b/tests/cond5.test @@ -48,15 +48,16 @@ $ACLOCAL $AUTOMAKE 2stderr pid=$! -# MSYS bash seems to have a bug in kill, so don't try to kill too soon. -sleep 2 +# MSYS bash seems to have a bug in kill, so don't try to kill too soon; +# and avoid maintainer-check test. +sleep '2' # Make at most 30 tries, one every 10 seconds (= 300 seconds = 5 min). try=1 while test $try -le 30; do if kill -0 $pid; then : process $pid is still alive, wait and retry -sleep 10 +sleep '10' try=`expr $try + 1` else cat stderr 2
Re: New auxiliary archive script
Hello Karl, * Peter Rosin wrote on Fri, Aug 06, 2010 at 01:43:03PM CEST: Add new auxiliary 'ar-lib' script, wrapping Microsoft lib. * lib/ar-lib: New auxiliary script. [...] could you please adjust your scripts to also autoupdate the 'ar-lib' script from Automake to Gnulib, just like done with 'compile' and other scripts already? Thanks, Ralf
Re: [PATCH] Modernize, improve and/or extend tests `colon*.test.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 06:06:04PM CEST:
At Sunday 08 August 2010, Ralf Wildenhues wrote:
No. You save a fork with
foo ()
{
...
foo_result=bar
}
foo ARG...
test $foo_result = ...
Yes, but how do you get foo_result in our case? ;-)
With sed, of course.
which we've been doing a lot in Libtool and Autoconf lately.
Yes, but using XSI variable substitutions and shell arithmetic, not
complex sed scripts.
That's not what I meant. We are using more than one strategy to speed
up things.
Or am I missing something?
I think you are. You proposed
result=`foo ...`
test $result = ...
which is an extra fork over the above, regardless of what foo does
internally.
Cheers,
Ralf
Re: [PATCH] Remove a couple of obsoleted tests.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 01:29:19PM CEST: At Sunday 08 August 2010, Ralf Wildenhues wrote: Except this would have been caught by make check already, so it doesn't count as an argument in favor of that patch, right? ;-) But make check is slooow on my machine, so when I change just a couple of test script I re-test them doing: $ cd tests make check -jN TESTS='foo.test bar.test ...' This way it's easy to miss errors like the one you pointed out. Point taken; I will look at the patch again. Thanks, Ralf
Re: [PATCH] Minor improvements and fixes in tests `depcomp*.test'.
* Stefano Lattarini wrote on Tue, Jun 22, 2010 at 06:48:00PM CEST: Yet another testsuite-tweaking patch. * tests/depcomp.test: Do not create useless dummy source files. Add a trailing `:' command. * tests/depcomp2.test: Use `unset' on the CFLAG variable to ensure it's not in in the environment, rather than exporting it with an empty value. Do not pass CC=gcc to configure, as that's already done in ./defs since we have gcc in $required. Ensure verbose printing of captured stderr, and normalize its checking. Add a trailing `:' command. * tests/depcomp3.test: Quote literal dots and dollar characters in grep regexps. Always use `: ' rather than `touch' to create empty files. Explicitly declare phony targets as such in the created Makefile.am. Add a trailing `:' command. * tests/depcomp4.test: Quote literal dots and dollar characters in grep regexp. Explicitly declare phony targets as such in the created Makefile.am. Ensure verbose printing of captured makes' stoud/stderr. Add a trailing `:' command. * tests/depcomp5.test: Move setting of `errexit' shell flag earlier in the script (just after inclusion of ./defs). Quote literal dots and dollar characters in grep regexps. Explicitly declare phony targets as such in the created Makefile.am. Add a trailing `:' command. * tests/depcomp6.test: Consistently use m4 quoting in the generated configure.in. Cosmetic fixes to spacing. Add a useful comment about an apparently useless use of an `if' statement. * tests/depcomp7.test: Likewise, and add a trailing `:' command. This one needs fixes. --- a/tests/depcomp2.test +++ b/tests/depcomp2.test @@ -43,11 +43,12 @@ END : subdir/foo.c # Ignore user CFLAGS. -CFLAGS= -export CFLAGS +unset CFLAGS Unsetting a variable which is not set can cause nonzero exit status; see autoconf.info. This code has errexit set. --- a/tests/depcomp6.test +++ b/tests/depcomp6.test @@ -20,11 +20,11 @@ set -e -cat configure.in 'END' +cat configure.in 'END' Tsk. AC_PROG_CC AM_PROG_CC_C_O AC_PROG_RANLIB -AC_CONFIG_FILES(sub2/Makefile) +AC_CONFIG_FILES([sub2/Makefile]) AC_OUTPUT END @@ -94,6 +94,11 @@ else cd sub2 $sleep echo 'choke me' sub3/ba3.h + # Do not use `$MAKE Exit 1' here, since even relatively-recent + # versions of the BSD shell wrongly exit when the `errexit' shell + # flag is active if a command within fails inside a compound + # statement. if $MAKE; then Exit 1; fi I guess that is missing 'else :;' then, too, so that the result of the compound command is zero. Likewise depcomp7.test. fi + : Thanks, Ralf
Re: [PATCHES] Bootstrap: Allow user overriding of $AUTOCONF and $PERL.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 12:53:21PM CEST: At Sunday 08 August 2010, Ralf Wildenhues wrote: Also, regenerating the tree with Autoconf 2.67 and committing that separately is preapproved for maint. Couldn't this cause problems when later merging to master? If yes, how would those be better solved? This is solved most easily by having one commit in maint that regenerates the tree, and merging that in the active branches. You may want to do a fake merge in this case to force a correctly created configure script for the branches ... Wait a couple of minutes, I'll do it and push right away. Cheers, Ralf
Re: [PATCH] Tweak, extend and improve tests `cond[a-z]*.test'.
Hello Stefano, * Stefano Lattarini wrote on Wed, Jul 14, 2010 at 03:26:04PM CEST: * tests/condd.test: Add trailing `:' command. Typofix in comment. Prefer fgrep over grep. * tests/condhook.test: Make sure target `install-data-hook' is not called by `make install', but that data files are installed. Use proper m4 quoting in configure.in. Add trailing `:' command. * tests/condhook2.test: New test, sister test of condhook, with inverted semantic. * tests/condinc2.test: Use proper m4 quoting in configure.in. Prefer trailing `:' command over trailing `Exit 0'. * tests/condman2.test: Enable errexit shell flag, and related changes. Add trailing `:' command. * tests/condman.test: Likewise. Also, do not create useless dummy manpages, and use proper m4 quoting in configure.in. * tests/condman3.test: New test, similar to condman.test, but it also runs ./configure and make install, and check the installed files. * tests/Makefile.am (TESTS): Updated. Well, allow me to be really nitpicky on this one. --- a/tests/condd.test +++ b/tests/condd.test @@ -64,7 +64,9 @@ mkdir foo bar $ACLOCAL $AUTOCONF -grep meaningless;characters configure Exit 1 +$FGREP meaningless;characters configure Exit 1 Such changes are just noise, right? As such, I don't think they improve the testsuite, they only add work to possible history digging later. --- a/tests/condhook.test +++ b/tests/condhook.test @@ -22,15 +23,16 @@ set -e cat configure.in 'END' -AM_CONDITIONAL(TEST, false) +AM_CONDITIONAL([TEST], [false]) AC_OUTPUT END cat Makefile.am 'END' -sysconf_DATA = mumble +datadir = $(prefix)/data +data_DATA = mumble Why this change? To me, this is just more complex noise, because harder to understand; or is there an actual bug in the test fixed by this? --- a/tests/condinc2.test +++ b/tests/condinc2.test @@ -22,9 +22,11 @@ set -e cat configure.in 'END' -AM_CONDITIONAL(TOBE, false) +AM_CONDITIONAL([TOBE], [false]) END +$ACLOCAL + cat Makefile.am 'END' if TOBE include adjunct @@ -37,7 +39,6 @@ target: dependency endif END -$ACLOCAL AUTOMAKE_fails Again, this moving of $ACLOCAL is noise, right? The rest seems good for maint, thanks. Ralf
Re: [PATCH] Modernize, improve and/or extend tests `colon*.test.
* Stefano Lattarini wrote on Thu, Aug 05, 2010 at 01:54:20PM CEST: Ping on this? It seems to me that most issues with this patch had already been solved, so it's probably a pity to let it bitrotting here... Well, I'd prefer the extract_dependencies script approach which would be more correct and not the complicated perl script which wasn't as correct. And the relaxed file distribution test. ;-) Thanks, and sorry for the delay, Ralf
Re: [PATCH] Minor improvements for tests `acloca*.test'.
* Stefano Lattarini wrote on Sun, Jun 27, 2010 at 04:48:03PM CEST:
Another testsuite-tweaking patch. This time, the changes should be
small and simple.
Minor improvements for tests `acloca*.test'.
This is not ok. Let's just drop everything from it except for the
changes I've copied below. Thanks.
--- a/tests/acloca19.test
+++ b/tests/acloca19.test
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2005 Free Software Foundation, Inc.
+# Copyright (C) 2005, 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
@@ -41,9 +41,11 @@ END
$ACLOCAL
$AUTOCONF
-./configure stdout
+./configure stdout || { cat stdout; Exit 1; }
cat stdout
--- a/tests/aclocal.test
+++ b/tests/aclocal.test
@@ -27,18 +27,20 @@ test -f fred
$ACLOCAL --output 2stderr { cat stderr 2; Exit 1; }
cat stderr 2
grep 'option.*--output.*an argument' stderr
-grep help stderr
+grep '[Tt]ry.*--help.*for more information$' stderr
Please don't match end of line. Two more instances below.
$ACLOCAL --unknown-option 2stderr { cat stderr 2; Exit 1; }
cat stderr 2
grep 'unrecognized.*--unknown-option' stderr
-grep help stderr
+grep '[Tt]ry.*--help.*for more information$' stderr
$ACLOCAL --ver 2stderr { cat stderr 2; Exit 1; }
cat stderr 2
grep 'unrecognized.*--ver' stderr
-grep help stderr
+grep '[Tt]ry.*--help.*for more information$' stderr
--- a/tests/aclocal5.test
+++ b/tests/aclocal5.test
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
+# Copyright (C) 2003, 2004, 2005, 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
@@ -55,16 +55,18 @@ echo 'AU_ALIAS([AM_TEST], [AC_SUBST])' m4/moredefs.m4
# Make sure configure dependencies are distributed.
$MAKE distdir
-test -f aclocal5-1.0/m4/moredefs.m4
+test -f $me-1.0/m4/moredefs.m4
--- a/tests/aclocal6.test
+++ b/tests/aclocal6.test
# Make sure configure dependencies are distributed.
$MAKE distdir
-test -f aclocal6-1.0/m4/moredefs.m4
-test -f aclocal6-1.0/m4/somedefs.m4
-test -f aclocal6-1.0/acinclude.m4
+test -f $me-1.0/m4/moredefs.m4
+test -f $me-1.0/m4/somedefs.m4
+test -f $me-1.0/acinclude.m4
diff --git a/tests/aclocal8.test b/tests/aclocal8.test
index ac10aff..acc694e 100755
--- a/tests/aclocal8.test
+++ b/tests/aclocal8.test
-$ACLOCAL -I m4 output 21
+$ACLOCAL -I m4 output 21 || { cat output; Exit 1; }
cat output
Cheers,
Ralf
transform2.test failure on Cygwin: replacing an executable with a script
I'm seeing a presumably new failure on Cygwin that I don't remember seeing before. The gist is the following: transform2.test tries something like install bla.exe .../inst/bin/foo.exe install script.sh .../inst/bin/foo and the second one fails (to overwrite the foo.exe). Does anybody happen to know if this is due to a change in Cygwin semantics? If yes, then the question is whether we should work around it somehow, like removing the old program first, so that 'make install' of a package upgrade that reimplements some program as a script might fail; OTOH, this should probably be done on w32 only, since foo might be a tool used during installation (such as 'install'). Ouch. I can't see why an Automake bug should be involved in this failure. Thanks, Ralf
Re: [PATCH] Separate failing part of test `all.test'.
* Stefano Lattarini wrote on Wed, Jul 14, 2010 at 01:36:57PM CEST: * tests/all.test: Run aclocal only once. Minor cosmetic changes. Move checks that several *-local's in a single rule work ... This sentence does not make sense to me. Maybe a missing word? * tests/manylocal.test: ... in this new test. * tests/Makefile.am (TESTS): Updated. (XFAIL_TESTS): Remove `all.test', add `manylocal.test'. Patch is OK, but I'd be happier if you could rename all.test to all2.test and manylocal.test to all.test (with adjustments to Makefile.am of course) so that - it is clearer that all and all2 are related, - comparison with old testsuite log results are still meaningful. I have many old log files lying around on several systems, and I tend to use them to find out quickly if some bug is long-standing on this system or new. Thanks, Ralf
Re: [PATCH] Modernize, improve and extend tests `subobj*.test'.
* Stefano Lattarini wrote on Wed, Jul 14, 2010 at 03:41:14PM CEST:
* tests/subobjname.test: Add trailing `:' command.
* tests/subobj.test: Make grepping of `Makefile.in' stricter.
Escape literal dots in grep regexps.
* tests/subobj2.test: Add trailing `:' command. Do not use the
unportable fgrep option `-e'. Make grepping of `Makefile.in'
stricter.
* tests/subobj3.test: Add trailing `:' command.
(configure.in): Use proper m4 quoting, and avoid obsolescent
constructs.
* tests/subobj8.test: Likewise. Also, enable `errexit' shell
flag, with related changes
* tests/subobj4.test: Likewise. Also, make grepping of
`Makefile.in' stricter.
* tests/subobj5.test: Add trailing `:' command. Move setting of
`errexit' shell flag earlier in the script (just after inclusion
of ./defs).
(configure.in): Use the stub created by `./defs', rather than
writing it from scratch, and avoid obsolescent constructs.
* tests/subobj6.test: Add trailing `:' command. Move setting of
`errexit' shell flag earlier in the script (just after inclusion
of ./defs). Do not create useless dummy ac-init file `f'.
* tests/subobj7.test: Do not create useless dummy ac-init file
`f'. Prefer fgrep over grep.
(configure.in): Use the stub created by `./defs', rather than
writing it from scratch, and avoid obsolescent constructs.
* tests/subobj9.test: Move setting of `errexit' shell flag earlier
in the script (just after inclusion of ./defs). Fail the test if
`make distcheck' fails. Ensure verbose printing of captured make
stdout.
(configure.in): Normalize the call to AC_INIT w.r.t. other tests.
(Makefile.am): Explicitly mark target print as phony.
* tests/subobj10.test: Removed duplicated call to `set -e'. Add
trailing `:' command.
(configure.in): Normalize the call to AC_INIT w.r.t. other tests.
OK for maint with nits below addressed, thanks!
Ralf
--- a/tests/subobj2.test
+++ b/tests/subobj2.test
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 1999, 2001, 2002 Free Software Foundation, Inc.
+# Copyright (C) 1999, 2001, 2002, 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
@@ -33,6 +33,8 @@ END
$ACLOCAL
$AUTOMAKE
-$FGREP 'generic/a.$(OBJEXT)' Makefile.in
+grep '^generic/a\.\$(OBJEXT):' Makefile.in
Some day I'll add initial and trailing space to the target names of all
generated rules to see how portable our test suite is ... ;-)
--- a/tests/subobj7.test
+++ b/tests/subobj7.test
@@ -37,6 +35,6 @@ END
$ACLOCAL
$AUTOMAKE --add-missing
-grep wish_CFLAGS Makefile.in Exit 1
+$FGREP wish_CFLAGS Makefile.in Exit 1
Tsk.
--- a/tests/subobj8.test
+++ b/tests/subobj8.test
@@ -33,12 +36,14 @@ cat Makefile.am 'END'
SUBDIRS = foo
END
-cat foo/Makefile.am 'EOF'
+cat foo/Makefile.am 'END'
AUTOMAKE_OPTIONS = subdir-objects
bin_PROGRAMS = mumble
mumble_SOURCES = bar/a.c
-EOF
+END
Another one of those needless changes.
--- a/tests/subobj9.test
+++ b/tests/subobj9.test
@@ -65,17 +64,19 @@ $AUTOMAKE -a
-$MAKE distcheck 21 | tee out
+$MAKE distcheck out 21 || { cat out; Exit 1; }
+cat out
s/out/output/g ?
Re: [PATCH] Remove a couple of obsoleted tests.
* Stefano Lattarini wrote on Wed, Jul 14, 2010 at 01:16:28PM CEST:
Remove a couple of obsoleted tests.
* tests/fpinstall.test: Removed.
* tests/fpinst2.test: Likewise.
OK for maint, but only if you also update tests/Makefile.{am,in}
to avoid subsequent testsuite failure. ;-)
Cheers,
Ralf
Re: [PATCH] Modernize, improve and extend tests `subobj*.test'.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 12:44:32PM CEST: At Sunday 08 August 2010, Ralf Wildenhues wrote: -$FGREP 'generic/a.$(OBJEXT)' Makefile.in +grep '^generic/a\.\$(OBJEXT):' Makefile.in Some day I'll add initial and trailing space to the target names of all generated rules to see how portable our test suite is ... ;-) I assume the change is OK, though... is it? Are you trying to resurrect the discussion about whether tests should exploit internal details more than necessary? We've been there before, I think. -cat foo/Makefile.am 'EOF' +cat foo/Makefile.am 'END' AUTOMAKE_OPTIONS = subdir-objects bin_PROGRAMS = mumble mumble_SOURCES = bar/a.c -EOF +END Another one of those needless changes. It is to enhance consistency within the test script... should I revert it nonetheless? I don't really care. In my very humble opinion, such questions take time that could be used more productively on Automake development. Also, what about squashing in this additiona change, to avoid a useless fork (and a useless involution)? Sure. Cheers, Ralf
Re: [INFO] push + merge delayed
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 07:17:49PM CEST: I just want state explicitly that I'll wait until tomorrow (or even the day after) to merge and push the patches we have reviewed this afternoon, since the time for today is almost out, and I don't want to do a push without proper testing. Take as much time as you need, there is no hurry. If origin/maint has advanced since, and you want to avoid re-doing merges, just merge it in rather than rebasing. Let's use this git feature to our advantage. Cheers, Ralf
Re: [PATCH] Modernize, improve and/or extend tests `colon*.test.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 04:38:08PM CEST: At Sunday 08 August 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Thu, Aug 05, 2010 at 01:54:20PM CEST: Ping on this? It seems to me that most issues with this patch had already been solved, so it's probably a pity to let it bitrotting here... Well, I'd prefer the extract_dependencies script approach I like the idea, too, but as I said I'd prefer to leave for a later patch. That's fine of course. Just leave the corresponding code unchanged then. which would be more correct and not the complicated perl script which wasn't as correct. Why not as correct? You said in a previous mail: A shell function in defs.in 'extract_makefile_deps TARGET FILE' that contains a sed script similar to extract_makefile_var that does what you want, and respects backslash-newline? But why should that function preserve backslash-newline occurrences? Is not this an internal detail due to automatical line-wrapping by Automake, which we should therefore ignore? No, it is an official API of 'make' that we program against. With tgt1 tgt2 \ tgt3 : dep1 dep2 \ dep3 \ dep4 Posix is perfectly clear about the list of targets and the list of dependencies. extract_makefile_deps can extract that. You're then still relying on not having $(macros) in the lists, so there is still an internal detail there, but I don't know how to avoid that easily. An even much more better check would be to only check semantics, i.e., that some target is actually updated when some dependency is outdated. Cheers, Ralf
Re: [PATCH] Modernize, improve and extend tests `pr*.test'.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 04:06:32PM CEST: At Sunday 08 August 2010, Ralf Wildenhues wrote: ok with it if you also add more meaningful descriptions to the tests, say, the PR descriptions. I'd love to do that (maybe as a separate patch to be applied *before* this one?). Do you know where (and if) I can find the original description of the reports? Oh, sorry, I thought that was clear. The Automake GNAT is at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake and mostly unused today. It is linked from the sourceware Automake home page, http://sources.redhat.com/automake/, and yeah, having two homepages is suboptimal. Cheers, Ralf
Re: [PATCH] Modernize, improve and/or extend tests `colon*.test.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 05:48:58PM CEST:
At Sunday 08 August 2010, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 05:35:57PM CEST:
foo=`extract_makefile_deps tgt2 Makefile`; echo x$foox
More or less, yes. I'd avoid the command substitution fork by
letting extract_makefile_deps set some variable instead of
printing.
So the we'd have move the comamnd substitution inside the function?
;-)
No. You save a fork with
foo ()
{
...
foo_result=bar
}
foo ARG...
test $foo_result = ...
which we've been doing a lot in Libtool and Autoconf lately. Since it's
not quite as intuitive, an alternative is
foo ()
{
...
eval $1=bar_suitably_escaped
}
foo result_var ARG...
test $result_var = ...
Cheers,
Ralf
Re: [PATCH] Modernize, improve and/or extend tests `colon*.test.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 05:35:57PM CEST: I'm just saying that when we'll write the `extract_makefile_deps' function, it shouldn't bother with preserving tabs and backslashes; Well, it should deal with them correctly, yes. on the other hand, it should actively normalize them to space in order to simplify grepping and matching of the extracted info. I think we violently agree. So that, with your example below, something like: foo=`extract_makefile_deps tgt2 Makefile`; echo x$foox should print: x dep1 dep2 dep3 dep4 x More or less, yes. I'd avoid the command substitution fork by letting extract_makefile_deps set some variable instead of printing. Have I managed to make my point now? If yes, what do you think of my proposal? Good. Thanks, Ralf
Re: [PATCH] Improve and extend tests `asm*.test'.
* Stefano Lattarini wrote on Wed, Jul 14, 2010 at 02:19:20PM CEST: * tests/asm.test: Use configure.in stub generated by ./defs, and avoid obsoleted autoconf constructs. Make grepping of Automake stderr stricter. Do not create useless source file. Improve verbose messages. Minor cosmetic changes. Tell to keep it in sync with other sister tests asm*.test. * tests/asm2.test: Likewise. * tests/asm3.test: Likewise. OK with nits below addressed. Thanks, Ralf --- a/tests/asm.test +++ b/tests/asm.test +echo '*** Run 1 -- Should fail because we need CC and CCAS ***' s/Run/Try/ ? s/Should/should/ ? +echo '*** Run 4 -- We have every needed, expect a success ***' s/every/thing/ several instances in the patch s/ a / / --- a/tests/asm2.test +++ b/tests/asm2.test AUTOMAKE_fails -grep AM_PROG_AS stderr +grep 'define .*am__fastdepCCAS.* add .*AM_PROG_AS' stderr I prefer not grepping for internal details like am__fastdepCCAS. More than one instance in the patch.
Re: [PATCH] Remove a couple of obsoleted tests.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 01:04:14PM CEST:
At Sunday 08 August 2010, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Wed, Jul 14, 2010 at 01:16:28PM CEST:
Remove a couple of obsoleted tests.
* tests/fpinstall.test: Removed.
* tests/fpinst2.test: Likewise.
OK for maint, but only if you also update tests/Makefile.{am,in}
to avoid subsequent testsuite failure. ;-)
Oops *blush*.
(That's why I'd like my Testsuite: check the list of test script
patch installed ;-)
Except this would have been caught by make check already, so it
doesn't count as an argument in favor of that patch, right? ;-)
Cheers,
Ralf
on merging patches (was: [PATCHES] Bootstrap: Allow user overriding of $AUTOCONF and $PERL.)
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 12:53:21PM CEST: At Sunday 08 August 2010, Ralf Wildenhues wrote: Fine with me. If you have all your patches in branches Yes, a branch for every patch (series). or otherwise ordered, you can also just wait until I'm done reviewing and commit or merge them in your preferred order. Whatever seems easier for you. I should have no problem with my workflow; git is very flexible. But thanks for your concerns. Well, if it helps you, there is no need to maintain a linear history in the maint branch. You can also just merge your (fixed) patches from the branches where you have them, that is fine with me as well. No need to rebase or cherry-pick the patches if that would mean more work for you. Does that make sense to you? If not, then we can probably just forget it again. Thanks, Ralf
Re: [PATCH] Modernize, improve and/or extend test scripts `conf*.test'.
Hi Stefano,
* Stefano Lattarini wrote on Sun, Jun 27, 2010 at 06:14:41PM CEST:
More testsuite tweakings. But this patch also contains some real
improvements and useful extensions IMO.
OK with nits below addressed. If I'm appearing too grumpy, then I'm
sorry about that, so let me tell you that I'm grateful that you've done
all this testsuite work, and I'm sorry there is such a high review
delay.
Thanks,
Ralf
Modernize, improve and/or extend test scripts `conf*.test'.
* tests/confh5.test: Cosmetic changes.
* tests/conff.test: Likewise.
* tests/confdeps.test: Likewise.
* tests/conflnk.test: Likewise.
* tests/conflnk2.test: Likewise.
* tests/confsub.test: Likewise.
* tests/confvar.test: Likewise, and make grepping of Makefile.in
stricter.
* tests/confvar2.test: Likewise.
* tests/conflnk3.test: Cosmetic changes, and re-enable a temporarly
disabled test (which didn't work with autoconf = 2.59, but now we
are requiring autoconf 2.62, so...)
* tests/conflnk4.test: Cosmetic changes, and extend existing tests
accordingly to TODO comments.
* tests/conff2.test: Make grepping of Automake's stderr stricter.
Add some comments explaining why we don't use the `configure.in'
stub preset be ./defs.
* tests/confh.test: Use the `configure.in' stub created by ./defs,
rather than writing one from scratch, and do not call AC_OUTPUT.
Enable `errexit' shell flag, and related changes. Prefer diff over
cmp to compare text files. Prefer perl over sed to fetch the value
of $(DIST_COMMON) from Makefile.in. Make grepping of the contents
of $(DIST_COMMON) stricter.
* tests/confh4.test: Use the `configure.in' stub created by ./defs,
rather than writing one from scratch. Make grepping of Makefile.in
stricter.
* tests/confh5.test: Make grepping of `config.h' stricter. Add a
comment.
* tests/configure.test: Avoid obsolescent constructs in generated
`configure.ac'. Do not write `configure.in' two times. Escape
literal dots in grep regular expressions.
* tests/confincl.test: Enable `errexit' shell flag, and related
changes. Prefer fgrep over grep. Other cosmetic changes.
* tests/config.test: Renamed to ...
* tests/confh3.test: ... this. Fix m4 quoting in `configure.in',
I'm not overly fond of the two renamings in this patch, again for
old log file reasons: confh2 and confh3 used to be tests, but they
were removed (and, BTW, for a very good reason: they did not check
effects, but internal details of makefiles ;-) see
git log -p -- tests/confh2.test tests/confh3.test
Consequently, I prefer not reusing those names. As to renaming them
to, say, confh[67].test, well, seems slightly more sensible but still
has the problem that old log files will be less helpful then.
and make grepping of `config.h' and `config.h.in' stricter.
* tests/conf2.test: Renamed ...
* tests/confh2.test: ... to this. Use the `configure.in' stub
created by ./defs, rather than writing one from scratch. Try to
run the checks both with and without AC_PROG_CC and AC_OUTPUT in
`configure.in'.
* tests/Makefile.am (TESTS): Updated.
--- a/tests/conff2.test
+++ b/tests/conff2.test
@@ -20,6 +20,8 @@
set -e
+# We avoid using configure.in stub initialized by ./defs, since we need
+# to keep track of line numbers (to grep for error messages).
Nice.
cat configure.in END
AC_INIT([$me], [1.0])
AM_INIT_AUTOMAKE
--- a/tests/confh.test
+++ b/tests/confh.test
@@ -33,24 +33,26 @@ mkdir include
: include/Makefile.am
: include/config.h.in
-$ACLOCAL || Exit 1
-$AUTOMAKE || Exit 1
-
-(sed -n -e '/^DIST_COMMON =.*\\$/ {
- :loop
- p
- n
- t clear
- :clear
- s/\\$/\\/
- t loop
- p
- n
- }' -e '/^DIST_COMMON =/ p' Makefile.in | grep acconfig.h) || Exit 1
+$ACLOCAL
+$AUTOMAKE
+
+perl -ne '
+if (s/^DIST_COMMON *=//)
+{
+ $_ .= while (s/\\$//);
+ $_ = $_ ;
+ s/\s+/ /g;
+ print $_\n;
+ exit 0;
+}' Makefile.in dc.txt
This could instead use extract_variable which we've discussed before
somewhere, right? ;-)
+cat dc.txt # might be useful for debugging.
+$FGREP ' acconfig.h ' dc.txt
diff --git a/tests/conf2.test b/tests/confh2.test
similarity index 84%
rename from tests/conf2.test
rename to tests/confh2.test
index 8e53733..fce254e 100755
--- a/tests/conf2.test
+++ b/tests/confh2.test
@@ -21,12 +21,8 @@
set -e
-cat configure.in 'END'
-AC_INIT
-AM_INIT_AUTOMAKE(nonesuch, nonesuch)
-AM_CONFIG_HEADER(config.h two.h)
-AC_PROG_CC
-AC_OUTPUT(Makefile)
+cat configure.in 'END'
+AM_CONFIG_HEADER([config.h two.h])
END
: Makefile.am
@@ -36,3 +32,15 @@ END
$ACLOCAL
$AUTOMAKE
+
+# Try again with more macros.
+
+cat configure.in 'END'
+AC_PROG_CC
+AC_OUTPUT
+END
+
+$ACLOCAL
This needs --force to be reliably effective.
+$AUTOMAKE
--- a/tests/confh4.test
+++ b/tests/confh4.test
@@ -50,4 +49,6 @@ mkdir include
$ACLOCAL
$AUTOMAKE
-$EGREP '^DEFAULT_INCLUDES =.*
Re: [PATCH] Modernize, improve and/or extend tests `colon*.test.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 06:22:00PM CEST:
Exactly! So:
foo() { foo_result=`sed ...`; }
foo; bar=$foo_result;
instead of:
foo() { sed ...; }
bar=`foo`
Where is the significant improvement?
Two forks vs. one: the latter still forks right before exec'ing sed.
Arguably, this is less important in the testsuite than it is in hot
spots in configure and libtool.
Cheers,
Ralf
Re: [PATCH] Modernize, improve and extend tests `pr*.test'.
* Stefano Lattarini wrote on Wed, Jul 14, 2010 at 03:35:11PM CEST: Modernize, improve and extend tests `pr*.test'. * tests/pr2.test: Add trailing `:' command. * tests/pr229.test: Likewise. * tests/pr401.test: Likewise. * tests/pr401b.test: Likewise. * tests/pr401c.test: Likewise. * tests/primary3.test: Likewise. * tests/pr211.test: Likewise. Also, use the `configure.in' stub created by `./defs', rather than writing it from scratch. * tests/pr204.test: Likewise, plus cosmetic spacing changes. * tests/pr287.test: Likewise, and move setting of `errexit' shell flag earlier in the script (just after inclusion of ./defs). * tests/pr220.test: Make grepping of Automake's stderr stricter. Also, add trailing `:' command, and cosmetic changes in spacing. * tests/primary2.test: Likewise. * tests/primary.test: Likewise. * tests/pr224.test: Move setting of `errexit' shell flag earlier in the script (just after inclusion of ./defs). Do not export `CC=gcc' to configure explicitly (it's already exported globally in ./defs, since we have gcc in $required). Use the stub for `configure.in' created by `./defs', rather than writing it from scratch. Do not create dummy files required by gnu mode (e.g. README, NEWS), since we run automake in foreign mode anyway. * tests/prefix.test: Enable `errexit' shell flags, and related changes. Add a trailing `:' command. * tests/proginst.test: Likewise. * tests/pr87.test: Likewise. Also, do not create dummy files required by gnu mode (e.g. README, NEWS), since we run automake in foreign mode anyway. * tests/pr72.test: Enable `errexit' shell flags, and related changes. Extend existing checks a bit. * tests/pr9.test: Likewise. Also, avoid obolescent constructs in the generated `configure.in', and extend existing checks over the generated tarball a bit. * tests/pr243.test: Avoid obolescent constructs in the generated `configure.in'. Enable the `errexit' shell flag, and related changes. Cosmetic changes to spacing, add trailing `:' command, and add a FIXME comment. * tests/pr266.test: Likewise. * tests/pr279.test: Avoid obolescent constructs in the generated `configure.in'; also, use the `configure.in' stub created by `./defs', rather than writing it from scratch. Enable `errexit' shell flag, and related changes. Add trailing `:' command. * tests/pr279-2.test: Likewise, and make grepping of Makefile.in stricter. * tests/pr300-prog.test: Cosmetic changes to spacing, and add a trailing `:' command. * tests/pr300-lib.test: Likewise. * tests/pr300-ltlib.test: Likewise, and ensure verbose printing of captured make stdout. * tests/pr307.test: Move setting of `errexit' shell flag earlier in the script (just after inclusion of ./defs). Prefer fgrep over grep where possible, and escape literal dots in grep regular expressions. Also, add a trailing `:' command, and cosmetic changes to spacing. There is lots of noise in this patch. I'm close to saying no to it for that reason, but there is just enough improvement left that I'm ok with it if you also add more meaningful descriptions to the tests, say, the PR descriptions. For example, after the patch, I have no idea what pr9.test is about. If you'd change the summary line to: # Test for bug in PR 9: make dist incorrect when AC_CONFIG_AUX_DIR present then it would make a bit more sense. Thanks, Ralf
Re: [PATCH] Minor improvements to tests ar*.test.
* Stefano Lattarini wrote on Wed, Jul 14, 2010 at 01:45:34PM CEST: * tests/ar.test: Add trailing `:' command. * tests/ar2.test: Likewise, and make grepping of generated Makefile.in stricter. OK for maint, thanks! Ralf
Re: [PATCHES] Bootstrap: Allow user overriding of $AUTOCONF and $PERL.
[ the gnu list server seems down ATM; expect delays ] Hi Stefano, * Stefano Lattarini wrote on Wed, Jul 28, 2010 at 11:07:20AM CEST: At Wednesday 28 July 2010, Ralf Wildenhues wrote: But even then, when developing Automake you will need to be extra careful to never let autoconf be invoked from the rebuild rules; because then, it will run plain autoconf and not the $AUTOCONF that you set. Why? AUTOCONF is AC_SUBST by configure, so if I do: AUTOCONF=autoconf-2.67 ./boostrap AUTOCONF=autoconf-2.67 ./configure (please pass variables as arguments to configure, so config.status --recheck remembers them.) there should be no problem. Am I missing something? You're right. Only, that AUTOM4TE should be set, too, so that aclocal.tmp uses the right one. Maybe it's prudent to set that here, too. (BTW, if my understanding is correct, this would make a nice addition to HACKING, too). Yep. Changing that from an absolute file name to a non-absolute one is a bad idea, it breaks several test setups I have, How? The $PERL in bootstrap should be only substituted in the shebang lines of automake.tmp and aclocal.tmp, and both of these scripts are removed just after being run once by boostrap itself. Overlooked by me. The amended patches are attached, with a new follow-up patch doing some fixlets for bootstrap. Thanks, OK for maint with $AUTOM4TE handling folded in as above. Cheers, Ralf From bf4e7ecea7feae34056b2e4382a2bef94642cb07 Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Tue, 27 Jul 2010 22:44:54 +0200 Subject: [PATCH 1/3] Bootstrap: let the user choose which autoconf to use. * bootstrap ($AUTOCONF): New variable, from the environment. Use it instead of calling autoconf directly. [...]
Re: [PATCH] Modernize, improve and/or extend test scripts `conf*.test'.
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 03:11:13PM CEST: At Sunday 08 August 2010, Ralf Wildenhues wrote: and I'm sorry there is such a high review delay. Well, I assume this is not done on purpose (right? ;-), so don't worry. That depends on how you interpret it, I guess. Testsuite work doesn't add new features to Automake. We have only finite amount of time for Free Software. If we spend all of that fixing the testsuite, there will be no time left for new features or bugs outside of the testsuite. And yes, with we I mean your time for Free Software as well. :-) Cheers, Ralf
Re: New auxiliary archive script
* Ralf Wildenhues wrote on Sat, Aug 07, 2010 at 08:03:56AM CEST: Darn, we need another name: 'archive' is likely too common when automake is going to put all files with that name in the distribution of each package using Automake. No need to send another patch, but any other good suggestions that fit in with the existing scripts? I don't find arlib so bad, except that it sounds a bit like a library rather than a program. arlib is already taken by some package of that name; let's go with ar-lib which seems unused, judging from codesearch, fairly close to the original suggestion, and hyphens are sort of GNU-ish anyway. ;-) That is, unless you dislike it. Thanks, Ralf
Call for help: Vala support in Automake
Here's the deal: At least two patch sets have been posted to Automake mailing lists during the last year in order to improve Vala support in Automake. We cannot take either because the authors couldn't complete copyright assignments for reasons not further relevant to this message. So here's a call for help: if there is something broken with Vala support in Automake, you can contribute by writing bug reports rather than by sending patches. Describe in your own words how things are supposed to work, or show your projects; given precise enough semantics, it is fairly straight-forward to fix the implementation. But we cannot do anything with nontrivial patches that are not assigned to the FSF, and in order to stay clean of potential problems I don't look at the patch posts at all. So *please* don't post them unless you're also willing to go all the way. Thanks, Ralf
Re: New auxiliary archive script
Darn, we need another name: 'archive' is likely too common when automake is going to put all files with that name in the distribution of each package using Automake. No need to send another patch, but any other good suggestions that fit in with the existing scripts? I don't find arlib so bad, except that it sounds a bit like a library rather than a program. Suggestions appreciated. Thanks, Ralf
Re: cond5.test spurious failure
* Peter Rosin wrote on Fri, Aug 06, 2010 at 04:11:20PM CEST: Please apply this on top of maint: Thanks, done. You can make us even happier if you submit patches with git format-patch $ref where $ref is the starting point you're basing on. I don't care whether you attach the files or send them as one email per patch. Stefano, sorry for not taking your patch; I saw Peter's earlier and had good success testing it on MinGW; also, I think it is easier to understand than yours. Hope you don't mind. Cheers, Ralf commit 146f01f899d677dbf02a41d55256a61d50a2b73c Author: Peter Rosin p...@lysator.liu.se Date: Fri Aug 6 16:03:52 2010 +0200 Make cond5.test more robust on MSYS. * tests/cond5.test: Add delay before the first kill attempt to cater for problems with MSYS bash.
Re: [PATCH] Fixlets and minor improvements for HACKING.
Hi Stefano, * Stefano Lattarini wrote on Fri, Aug 06, 2010 at 11:50:46AM CEST: Subject: [PATCH] Fixlets and minor improvements for HACKING. * HACKING: Add some missing fullstops in sentences. Remove some extra empty lines, for consistency. (Test suite): Add pointer to `tests/README'. (Admistrivia): Tell to mention important bug fixes in NEWS. OK for maint. Thanks! BTW, I just pushed out my current maint without having it merged into branch-1.11 or master. If it helps, then I will push maint more often but not always necessarily merge right away; merging from maint to any active branch at any time is preapproved however, so feel free to do it if you prefer. I assume this strategy is easier than letting patches sit locally waiting for a good time to merge. Cheers, Ralf
Re: Segmentation fault with Solaris /usr/xpg4/bin/make
Hello Stefano, * Stefano Lattarini wrote on Thu, Aug 05, 2010 at 07:40:15PM CEST: The test `parallel-tests9.test' fails on Solaris 10 when using /usr/xpg4/bin/make as $MAKE, due to a submake invocation returning an exit status `139' (i.e. a Segmantation fault). Thanks for the report. A segfault in make is always a bug in the make implementation. If we can easily find out what makes it fail, and can easily and reliably work around it, then let's maybe consider it, but otherwise let's not bother. The user can always install GNU make. Can you please report the issue to the relevant upstreams (heirloom and Solaris or OpenSolaris)? I would assume using valgrind on GNU/Linux to be easiest to pinpoint the bug, and/or debugging the core file. Thanks, Ralf
Re: New auxiliary archive script
* Peter Rosin wrote on Thu, Aug 05, 2010 at 11:10:38AM CEST: Den 2010-08-04 22:18 skrev Ralf Wildenhues: Now if you insist, then maybe we can just find another compromise name. Please set $me to the name and use that throughout, so at least a change is easily done. ;-) I'm perfectly fine with 'archive', so let's go back to that. I found only one problematic project on codesearch, and that was an ancient version of gimp (0.54, 1997?): http://archive.debian.org/debian-archive/debian/dists/Debian-1.3.1/contrib/source/gimp_0.54.1.orig.tar.gz A quick peek at more recent versions of gimp shows that they no longer have any clashing archive script. But I don't know when it was actually removed from from the gimp source. It does not appear to be there in gimp 2.4 from a couple of years ago. So let's use archive then. Thanks for the history digging. Should the AM_PROG_AR macro perhaps be required when AC_PROG_RANLIB is seen? Hmmm, but the ranlib macro is from autoconf so probably not... Oohh, I dunno. Please leave this to a separate patch anyway. (One really ugly but probably convenient way could be to just attach it to the beginning of AC_PROG_RANLIB at AM_INIT_AUTOMAKE expansion time. Not sure if that's TRT if Libtool is in the game, though.) I found a few nits, but nothing substantial, so if you can format your next iteration as git patch, and given testing, it can just go in. What branch should I base this on? master, maint or msvc? Doesn't matter. I will anyway cherry-pick it onto msvc which is currently at v1.11-157-gda15b99. Members can be specified on separate lines in a file named with @file. Please use @FILE not @file; the capitalization is already meant to denote metasyntactic variables (as is done by info pages). I wanted to, but binutils ar has this in its --help: @file - read options from file Hmm, but both 'ld --help' and 'nm --help' have @FILE Read options from FILE so I'm wondering whether @file was intentional or not. Might want to ask the binutils list about this (also, so they know we do these kinds of hacks). Or, just write a decent functionality test instead ... if test -n $delete; then if test ! -f $orig_archive; then Can it be a symbolic link or another non-regular file type? Won't $AR detect a non-existing file? I doubt that lib will work with anything but regular files. What I'm trying to accomplish is that lib will recreate the archive every time if you do lib -out:foo.lib foo.obj lib -out:foo.lib bar.obj lib -out:foo.lib baz.obj so that you end up with a foo.lib that only contains baz.obj. You have to do this: lib -out:foo.lib foo.obj lib -out:foo.lib foo.lib bar.obj lib -out:foo.lib foo.lib baz.obj to create an archive that contains all three objects (unless you create it all in one go of course). If foo.lib doesn't exist, lib falls over if you use the latter syntax. So, you have to know in advance if you are adding to an existing archive or if you are creating a new one. Per POSIX, ar should print a diagnostic if it has to create an archive and the c modifier isn't specified, so I just hooked that into the existing test. OK, thanks. $AR -NOLOGO -LIST $archive | while read member do func_file_conv $member $AR -NOLOGO -EXTRACT:$file $archive Does lib have no way to just extract the whole archive? No. Come on, what do you expect? :-) Ohh. I'm sorry for you and all other w32 users. Cheers, Ralf
Re: New auxiliary archive script
* Peter Rosin wrote on Fri, Aug 06, 2010 at 12:00:53AM CEST: Den 2010-08-01 20:06 skrev Ralf Wildenhues: For actual applicability, it is sufficient if you provide a working script, post testsuite results with it in place (you might want to MAKE='make AR=...' When I do MAKE='make AR=/path/to/archive lib' make AR=/path/to/archive lib check I get a whole bunch of failures when tests are running configure, the first one being aclocal4.test: Try passing in the environment, or in AM_MAKEFLAGS. Thanks, Ralf
Re: New auxiliary archive script
Hi Peter,
thanks for your work on this!
* Peter Rosin wrote on Wed, Aug 04, 2010 at 12:14:28PM CEST:
Den 2010-08-01 20:06 skrev Ralf Wildenhues:
Yes, in principle: when them bugs are fixed. Would you be willing to
rewrite the script so it
- has the blurb header similar to 'compile',
- half-way decent option handling (doesn't barf on shift if given too
few options, diagnoses unknown options, treats contents of ARFLAGS as
options not members, etc.)
- prints error messages on stderr and exits nonzero then,
I have all of the above fixed, with the (minor IMHO) limitation that
only archive members can be specified in @files. Also, I have not
fixed handling of ARFLAGS, since I don't understand what you mean.
The archiver has no knowledge of ARFLAGS, it just sees a bunch of
options, but I'm sure you know that so you must mean something
different...
Yes, I meant that it should have sane option handling. The things that
users pass in ARFLAGS end up as command line options to this script.
I wonder whether we can and should call it 'archive', or whether that
would clash with user file names in case they don't use
AC_CONFIG_AUX_DIR. OTOH, a script named 'ar' may not be installable
anywhere due to the ar binary already there. Thoughts?
Let's use the prefix am, and append the short form ar - amar. Because
who can resist a little bit of love in the source trees? FWIW, I came up
with no relevant hits for that in codesearch.
I'm really not that excited about the name: It doesn't make it too clear
what the tool does (unlike am-ar maybe) and we don't use the 'am' prefix
anywhere else: depcomp, compile, mkinstalldirs, gendocs, gnupload. Why
should that be different here? What's wrong with 'archive', is it taken
already? If you care about it wrapping MS lib only for now: it could
wrap other junk as well in the future, no?
Now if you insist, then maybe we can just find another compromise name.
Please set $me to the name and use that throughout, so at least a change
is easily done. ;-)
I found a few nits, but nothing substantial, so if you can format your
next iteration as git patch, and given testing, it can just go in.
-h | --h*)
cat \EOF
Usage: amar [--help] [--version] PROGRAM ACTION ARCHIVE [MEMBER...]
Members can be specified on separate lines in a file named with @file.
I think s/can/may/ sounds better because that is not mandatory.
Please use @FILE not @file; the capitalization is already meant to
denote metasyntactic variables (as is done by info pages).
EOF
# strip leading dash in $action
case $action in
-*) action=${action#-} ;;
esac
The case statement is unnecessary, you can use just
action=${action#-}
while test -n $action
do
case $action in
d*)
delete=yes
action=${action#d}
;;
x*)
extract=yes
action=${action#x}
;;
t*)
list=yes
action=${action#t}
;;
r*)
replace=yes
action=${action#r}
;;
c*)
create=yes
action=${action#c}
;;
u*)
# TODO: don't ignore update modifier
action=${action#u}
;;
You can factor out all the action=... lines to after the case statement
as
action=${action#?}
?*)
echo amar: unknown action specified 12
exit 1
;;
esac
done
if test -n $delete; then
if test ! -f $orig_archive; then
Can it be a symbolic link or another non-regular file type?
Won't $AR detect a non-existing file?
echo amar: archive not found 12
exit 1
fi
for member
do
case $1 in
@*)
# When interpreting the content of the @file, do NOT
# use func_file_conv, since the user would need to
# supply preconverted file names to binutils ar, at
# least for MinGW.
cat $...@} | while read file
do
$AR -NOLOGO -REMOVE:$file $archive
done
You can omit the cat and pipe and just
done $...@}
OTOH, it is common (at least in newer GCC and binutils) to allow @file
contents to be just whitespace-separated, including single or double
quoting. That could be done with something like
atfile_contents=`cat $...@}`
eval set x $atfile_contents
shift
which you might want to factor out into a function to reuse below.
I have no idea whether native w32 tools do something similar, though.
Shouldn't the script stop and fail if one of the $AR commands fails?
;;
*)
func_file_conv $1
$AR -NOLOGO -REMOVE:$file $archive
;;
esac
done
elif test -n $extract; then
if test ! -f $orig_archive; then
echo amar: archive not found 12
exit 1
Repeated code, could be in an 'error' function.
fi
if test $# -gt 0; then
for member
do
case $1 in
@*)
cat $...@} | while read file
do
$AR -NOLOGO -EXTRACT:$file $archive
done
Re: New auxiliary archive script
* Eric Blake wrote on Wed, Aug 04, 2010 at 11:04:29PM CEST:
On 08/04/2010 02:18 PM, Ralf Wildenhues wrote:
# strip leading dash in $action
case $action in
-*) action=${action#-} ;;
esac
The case statement is unnecessary, you can use just
action=${action#-}
Either way, this assumes an XSI shell. Are we guaranteed that this
script will only run on hosts where all shells understand this, or is it
likely to trip up on Solaris /bin/sh?
Rationale for just assuming an XSI shell for now was that users must be
pretty desparate to try to build using the MSVC compiler on Solaris.
Does wine work on Solaris? If so, then that is at least a theoretical
possibility; but in this case, since 'archive' is a new feature and thus
no reason to fear regressions, I'm willing to just give this test
balloon a try.
Cheers,
Ralf
Re: Recursive targets for the user
Hi Stefano, * Stefano Lattarini wrote on Mon, Aug 02, 2010 at 12:10:10PM CEST: At Sunday 01 August 2010, Ralf Wildenhues wrote: So, here's the deal: currently, Automake has RECURSIVE_TARGETS RECURSIVE_CLEAN_TARGETS AM_RECURSIVE_TARGETS Is there any good reason (apart from naybe backward-compatibility) for keeping these as three separate variables? Well, yes. clean targets need to a different subdir traversal order, and currently, the latter lists more than the sum of the former: it also lists targets that invoke `make' recursively within the same directory. The latter is needed in some cases (mostly for hidden dependencies), and listing them is needed in order to avoid unwanted parallel execution; writing a section about this necessity has been on my todo list for a while: the deal is that you should not run make -jN T1 T2 if both T1 and T2 are listed in $(AM_RECURSIVE_TARGETS). And yes, backward compatibility is very important, too. I've checked codesearch now, these variables are used elsewhere already. :-/ 1) What to name them? RECURSIVE_USER_TARGETS RECURSIVE_USER_CLEAN_TARGETS ALL_RECURSIVE_USER_TARGETS What about `EXTRA_RECURSIVE_TARGETS' etc. instead? Ah, that's a good idea; thanks. Also, I'd like to have a way to specify a recursive targers which should recurse in a limited set of a projects' subdirectories, and not in all of $(SUBDIRS). Do you think this would be possible/worthwhile? Can you give an example what this would be good for? My idea was that if the user adds a recursive target but then doesn't specify an *-am rule in some directory, that the rule would just traverse that directory without doing anything by default. So your suggestion would be optimization only, right? Thanks, Ralf
Re: Recursive targets for the user
* Stefano Lattarini wrote on Mon, Aug 02, 2010 at 09:25:46PM CEST: At Monday 02 August 2010, Ralf Wildenhues wrote: Also, I'd like to have a way to specify a recursive targers which should recurse in a limited set of a projects' subdirectories, and not in all of $(SUBDIRS). Do you think this would be possible/worthwhile? Can you give an example what this would be good for? Yes, I'd like to be able to do what proposed in this old patch series of mine: http://www.mail-archive.com/automake-patc...@gnu.org/msg01848.html without having to recurse to ugly cut-and-paste from lib/am/subdirs.am internals, like this: Yes, that would be usable with the new approach I suggested. Thanks for reminding me of your older report. My idea was that if the user adds a recursive target but then doesn't specify an *-am rule in some directory, that the rule would just traverse that directory without doing anything by default. But would it still recurse in that directory's subdirectories? Yes. If yes, everything's fine with your approach (even if we could then IMHO find a better naming than `*-am' for recusrive rules, but this is a minor point). Why, what's wrong with just documenting *-am? Otherwise, if I wanted a recursive target `foo' descending in say, bar/tests/ and baz/quux/tests/, it would still be necessary for me to add dummy `foo-am' (or `foo'?) targets to bar/Makefile.am, baz/Makefile.am and baz/quux/Makefile.am, and a dummy dependency like `foo-am: foo' to bar/tests/Makefile.am and baz/quux/tests/Makefile.am. No; the idea is that these dummies are added by automake already. Hmm, we might still need a way to differentiate between recursions that need to go into $(DIST_SUBDIRS) rather than $(SUBDIRS) ... Cheers, Ralf
Re: automake-1.11.1 - make check failure on AIX V8BETA - exeext4-p.dir and mkinst3.dir
Hi Rainer, * Rainer Tammer wrote on Sun, Aug 01, 2010 at 02:34:45PM CEST: I just tested automake-1.11.1 on AIX V7BETA. All make check tests succeed but two. Here are the two failures. I have also attached the complete test-suit.log. thanks for the bug report. Both failures are new to me, and I cannot reproduce them on AIX 6.3. FAIL: exeext4-p.test (exit: 1) == === Running test ./exeext4-p.test + pwd /daten/source/automake-1.11.1/tests/exeext4-p.dir + set -e + cat + 1 configure.in 0 /tmp/sh9830582.3 + cat + 1 Makefile.am 0 /tmp/sh9830582.5 + aclocal-1.11 -Werror autom4te: /usr/local/bin/m4 terminated by signal: 0 + exit_status=130 This is really weird, and kind of smells like flaky hardware or so, because I don't see why exeext4.test shouldn't fail if this one does. Can you do cp tests/test-suite.log tests/test-suite.log.backup make recheck to rerun both failing tests and see if the failure of this one is transient? Which autom4te and m4 versions is this happening with BTW? FAIL: mkinst3.test (exit: 1) === Running test ./mkinst3.test + pwd /daten/source/automake-1.11.1/tests/mkinst3.dir + set -e + mkdir ~a b + mkdir ~a b/-x y + rm -rf ~a b + cp /daten/source/automake-1.11.1/tests/../lib/mkinstalldirs . + ./mkinstalldirs ~a b/-x y mkdir -p -m 755 ~a b chmod: ~a: A file or directory in the path name does not exist. chmod: b: A file or directory in the path name does not exist. mkdir -p -m 755 ~a b/-x y chmod: ~a: A file or directory in the path name does not exist. chmod: b/-x: A file or directory in the path name does not exist. chmod: y: A file or directory in the path name does not exist. This looks completely broken already. Can you please post the output of type mkdir chmod Is /bin/sh the vendor shell? + test -d ~a b/-x y + rm -rf ~a b + mkdir bin + cat + 1 bin/mkdir 0 /tmp/sh10879018.3 + chmod +x bin/mkdir + AM_PATH=/daten/source/automake-1.11.1/tests:/usr/local/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/ java5/jre/bin:/usr/java5/bin::/usr/vac/bin:/usr/vacpp/bin + export AM_PATH + + pwd PATH=/daten/source/automake-1.11.1/tests/mkinst3.dir/bin:/daten/source/automake-1.11.1/tests:/usr/local/bin:/usr/bin:/ etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java5/jre/bin:/usr/java5/bin::/usr/vac/bin:/usr/vacpp/bin + export PATH + ./mkinstalldirs ~a b/-x y mkdir -p -m 755 ~a b mkdir -p -m 755 ~a b/-x y + exit_status=1 If this failure reoccurs with the recheck above, then can you please post the output of the following also: cd tests/mkinst3.dir rm -rf '~a b' /bin/sh -vx ./mkinstalldirs '~a b/-x y' echo $? rm -rf '~a b' (PATH=`pwd`/bin:$PATH; export PATH; /bin/sh -vx ./mkinstalldirs '~a b/-x y'; echo $?) Thanks, Ralf
