Re: automake results on OpenBSD 4.0
Hi Eric, * Eric Blake wrote on Wed, Jan 23, 2008 at 06:26:20AM CET: According to Eric Blake on 1/22/2008 10:22 PM: | FAIL: color.test | = | 1 of 526 tests failed | (95 tests were not run) | Please report to bug-automake@gnu.org | = | | I suspect this is because 'which expect' claims that expect is not | installed, in which case the test should be skipped rather than failed. This was on the master branch, not 1.10.1 (which doesn't have color support), tested on OpenBSD 4.0. Can you post output of the following please? cd tests TESTS=color.test VERBOSE=yes make -e check Thank you, Ralf
Re: automake results on OpenBSD 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 1/22/2008 11:12 PM: | | | | I suspect this is because 'which expect' claims that expect is not | | installed, in which case the test should be skipped rather than failed. | | This was on the master branch, not 1.10.1 (which doesn't have color | support), tested on OpenBSD 4.0. | | Can you post output of the following please? | cd tests TESTS=color.test VERBOSE=yes make -e check Colors correctly displayed (at least via my rxvt terminal hosting the ssh session to the machine in question). I used the BSD make. make defs aclocal-1.10a automake-1.10a `defs' is up to date. `aclocal-1.10a' is up to date. `automake-1.10a' is up to date. make check-TESTS /home/ericb/automake/tests:/home/ericb/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:. === Running test ./color.test + pwd /home/ericb/automake/tests/color.dir + set -e + TERM=ansi + export TERM + red= + grn= + lgn= + blu= + std= + cat + configure.in + END + cat + Makefile.am + END + cat + pass + END + cat + fail + END + cat + skip + END + cp fail xfail + cp pass xpass + chmod +x pass fail skip xpass xfail + aclocal-1.10a -Werror + automake-1.10a --foreign -Werror -Wall + autoconf + ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile + cat + expect-make + END + unset TESTS + make -e check + stdout + AM_COLOR_TESTS=always + cat stdout make pass fail skip xpass xfail `pass' is up to date. `fail' is up to date. `skip' is up to date. `xpass' is up to date. `xfail' is up to date. make check-TESTS PASS: pass FAIL: fail SKIP: skip XPASS: xpass XFAIL: xfail = 2 of 4 tests did not behave as expected (1 unexpected passes) (1 tests were not run) = *** Error code 1 Stop in /home/ericb/automake/tests/color.dir (line 268 of Makefile). *** Error code 1 Stop in /home/ericb/automake/tests/color.dir (line 402 of Makefile). + test_color : exit 1 FAIL: color.test = 1 of 1 tests failed Please report to bug-automake@gnu.org = *** Error code 1 Stop in /home/ericb/automake/tests (line 909 of Makefile). *** Error code 1 Stop in /home/ericb/automake/tests (line 938 of Makefile). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlt/b84KuGfSFAYARAumMAJ0TTi+tIZpSh3TwAqSf3RUnRTOydgCfWIya rp+0odWckIDYKJho886vflw= =5u5z -END PGP SIGNATURE-
[SCM] GNU Automake branch, branch-1-10, updated. Release-1-10-1-2-g90befd1
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Automake.
http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=90befd186ea00c4f347ce96c028359b9bbd714fb
The branch, branch-1-10 has been updated
via 90befd186ea00c4f347ce96c028359b9bbd714fb (commit)
from d3e929b8e88925df43fa887f9b275acd58eaf60e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 90befd186ea00c4f347ce96c028359b9bbd714fb
Author: Ralf Wildenhues [EMAIL PROTECTED]
Date: Tue Jan 22 23:35:57 2008 +0100
Prefer generated manpages over distributed ones.
* lib/am/mans.am (install-man%SECTION%): Prefer generated manpages
over distributed ones.
Report and patch by Peter Breitenlohner.
* tests/man3.test: New test.
* tests/Makefile.am: Update.
---
Summary of changes:
ChangeLog |8 ++
lib/am/mans.am |6 ++--
tests/Makefile.am |1 +
tests/Makefile.in |1 +
tests/{output-order.test = man3.test} | 40 ---
5 files changed, 29 insertions(+), 27 deletions(-)
copy tests/{output-order.test = man3.test} (53%)
diff --git a/ChangeLog b/ChangeLog
index 7af82a8..8cb05e4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2008-01-22 Ralf Wildenhues [EMAIL PROTECTED]
+ * lib/am/mans.am (install-man%SECTION%): Prefer generated manpages
+ over distributed ones.
+ Report and patch by Peter Breitenlohner.
+ * tests/man3.test: New test.
+ * tests/Makefile.am: Update.
+
+2008-01-22 Ralf Wildenhues [EMAIL PROTECTED]
+
* configure.ac, NEWS: Bump version to 1.10.1a.
2008-01-21 Ralf Wildenhues [EMAIL PROTECTED]
diff --git a/lib/am/mans.am b/lib/am/mans.am
index 29b8fea..2b5bac9 100644
--- a/lib/am/mans.am
+++ b/lib/am/mans.am
@@ -1,5 +1,5 @@
## automake - create Makefile.in from Makefile.am
-## Copyright (C) 1998, 2001, 2003, 2004, 2006 Free Software Foundation, Inc.
+## Copyright (C) 1998, 2001, 2003, 2004, 2006, 2008 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
@@ -44,8 +44,8 @@ install-man%SECTION%: $(man%SECTION%_MANS) $(man_MANS)
done; \
for i in $$list; do \
## Find the file.
- if test -f $(srcdir)/$$i; then file=$(srcdir)/$$i; \
- else file=$$i; fi; \
+ if test -f $$i; then file=$$i; \
+ else file=$(srcdir)/$$i; fi; \
## Change the extension if needed.
ext=`echo $$i | sed -e 's/^.*\\.//'`; \
case $$ext in \
diff --git a/tests/Makefile.am b/tests/Makefile.am
index f7fd00c..bb89110 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -361,6 +361,7 @@ makej.test \
makevars.test \
man.test \
man2.test \
+man3.test \
mclean.test \
mdate.test \
mdate2.test \
diff --git a/tests/Makefile.in b/tests/Makefile.in
index 7e2b640..2ae1852 100644
--- a/tests/Makefile.in
+++ b/tests/Makefile.in
@@ -493,6 +493,7 @@ makej.test \
makevars.test \
man.test \
man2.test \
+man3.test \
mclean.test \
mdate.test \
mdate2.test \
diff --git a/tests/output-order.test b/tests/man3.test
similarity index 53%
copy from tests/output-order.test
copy to tests/man3.test
index 620095d..2527e9c 100755
--- a/tests/output-order.test
+++ b/tests/man3.test
@@ -3,7 +3,7 @@
#
# 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)
+# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
@@ -14,39 +14,31 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see http://www.gnu.org/licenses/.
-# Test that `automake -a' output order is stable.
-# From report by Bruno Haible.
+# PR 516: Prefer generated manpages to distributed ones.
. ./defs || exit 1
set -e
+cat Makefile.am 'END'
+dist_man_MANS = foo.1
+installcheck-local:
+ grep bar $(mandir)/man1/foo.1
+END
+
cat configure.in 'END'
+: ${foo=foo}
+AC_SUBST([foo])
+AC_CONFIG_FILES([foo.1])
AC_OUTPUT
END
-: Makefile.am
-: AUTHORS
-: ChangeLog
-: NEWS
-: README
-
-cat .autom4te.cfg 'END'
-begin-language: Autoconf
-args: --no-cache
-end-language: Autoconf
-begin-language: Autoconf-without-aclocal-m4
-args: --no-cache
-end-language: Autoconf-without-aclocal-m4
+cat foo.1.in 'END'
[EMAIL
Re: AC_PROG_INSTALL: require installation of multiple files.
Hello Paul,
* Paul Eggert wrote on Wed, Jan 23, 2008 at 12:54:50AM CET:
Ralf Wildenhues [EMAIL PROTECTED] writes:
+that creates @file{install} from it if there is no makefile. Starting with
+Autoconf 2.62, this macro requires @command{install} to be able to install
+multiple files into a target directory.
A minor point: as a general rule, it's better not to put version
numbers into the manual like that, as it clutters up the manual
unnecessarily. Information about when features were added is best
left in NEWS. There are sometimes exceptions to that general rule
(incompatible changes come to mind), but this isn't one of them.
OK with me, I've applied the patch below.
Thanks for the rest of the change, by the way, it's a nice one.
My pleasure. It should lead to greatly reduced `make install' times.
Cheers,
Ralf
* doc/autoconf.texi (Particular Programs): Do not mention the
Autoconf version in which the AC_PROG_INSTALL change was done.
Suggested by Paul Eggert.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 4e32e08..78628e5 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -3730,9 +3730,9 @@ This macro screens out various instances of
@command{install} known not to
work. It prefers to find a C program rather than a shell script, for
speed. Instead of @file{install-sh}, it can also use @file{install.sh},
but that name is obsolete because some @command{make} programs have a rule
-that creates @file{install} from it if there is no makefile. Starting with
-Autoconf 2.62, this macro requires @command{install} to be able to install
-multiple files into a target directory in a single invocation.
+that creates @file{install} from it if there is no makefile. Further, this
+macro requires @command{install} to be able to install multiple files into a
+target directory in a single invocation.
Autoconf comes with a copy of @file{install-sh} that you can use. If
you use @code{AC_PROG_INSTALL}, you must include either
Re: GNU Automake 1.10.1 released
Hello, * NightStrike wrote on Tue, Jan 22, 2008 at 09:43:20AM CET: On 1/21/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: - Fix order of standard includes to again be `-I. -I$(srcdir)', followed by directories containing config headers. What was it before the fix? http://lists.gnu.org/archive/html/automake-patches/2007-11/msg00025.html Cheers, Ralf
Re: GNU Automake 1.10.1 released -- bug #516 is still there
On Tue, 22 Jan 2008, Ralf Wildenhues wrote: I'm pleased to announce the release of Automake 1.10.1. Automake is a tool Very good, BUT more than a year ago I filed a bug report (automake#516), after sending an email some month earlier: automake generated Makefiles install manpages from the source tree in preference to those from the build tree together with a tiny and IMHO uncontroversial patch solving this problem. I am terribly disappointed that I never got any reaction and that this bug is still present in the new release. regards Peter Breitenlohner [EMAIL PROTECTED]
Re: linking source files from a different directory macro
On Tue, 22 Jan 2008, Jason Roscoe wrote: I also saw AC_CONFIG_LINKS but I wasn't sure it would be appropriate for what I was trying to do. I'll have a look at it again. One other thing is that I would like the links to be removed during a 'make clean' step, e.g.. Do you know offhand if AC_CONFIG_LINKS will setup any rules to remove the links? It seems to me that this macro is intended to assist with configuring the package. It is not meant for drawing in a foreign source tree which Automake does not know about or does not obey VPATH rules. It seems that the links created by AC_CONFIG_LINKS are created by config.status so they should be removed by 'distclean' but not 'clean'. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Automake 1.10.1 released
On Tue, 22 Jan 2008, Ralf Wildenhues wrote: I'm pleased to announce the release of Automake 1.10.1. Any reason this never made it in? http://lists.gnu.org/archive/html/bug-automake/2005-10/msg00016.html -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: Automake (alpha) release request
Sebastian Pipping wrote: If the FSF handles this problem also putting out a non-alpha-non-beta 1.11 release of Automake before 2008-02-01 I will donate k Euros to the FSF with k equal the number of days left to that deadline, e.g. if Automake 1.11 is released on 2008-01-31 I will donate 1 Euro, for 2008-01-05 it would be 32 - 5 = 27 Euros. Time is UTC+0, 31 Euros is maximum, just to be on the safe side. I just noticed the release of Automake 1.10.1. It's not 1.11 as requested but it has LZMA support and is neither alpha nor beta. That's good enough for me. 32 - 21 equals 11, and according to the current exchange rate [1] 11 Euros make 16.0765 Dollars. Therefore I just donated 16.08 USD to the FSF. Things I noticed about the new release: * The GNU FTP Automake directory [2] holds a .sig.sig file: automake-1.10.1.tar.bz2.sig.sig . Is this by intention? * Automake 1.10.1 did not add a .tar.lzma release to itself. I think that would be an important part for promotion LZMA and should be fixed. Other than that great work, thanks to everybody who made it happen! Sebastian [1] http://finance.yahoo.com/currency/convert?amt=11+from=EURto=USDsubmit=Convert [2] http://ftp.gnu.org/gnu/automake/
Re: Automake (alpha) release request
Hello Sebastian, * Sebastian Pipping wrote on Tue, Jan 22, 2008 at 09:28:23PM CET: Things I noticed about the new release: * The GNU FTP Automake directory [2] holds a .sig.sig file: automake-1.10.1.tar.bz2.sig.sig . Is this by intention? No, that was due to a typo. Oh well, it was late, the extra file shouldn't hurt anybody. * Automake 1.10.1 did not add a .tar.lzma release to itself. I think that would be an important part for promotion LZMA and should be fixed. Good idea, done: ftp://ftp.gnu.org/gnu/automake/automake-1.10.1.tar.lzma. Cheers, Ralf
New mailing list automake-commit
The new mailing list http://lists.gnu.org/mailman/listinfo/automake-commit will soon receive git commit messages for the Automake repository. I find it cleaner if automake-patches is left for discussion of patches, and typically the mere commit notices lack space to add some rationale and so on. Cheers, Ralf
Compiling project requiring w/ source requiring different compilers
Hi everyone, I am currently learning the ins and outs of automake and I am attempting to incorporate it into a project I am working on. I have run into an issue that has me at wits end as I can't seem to find a way around it. I have a project that will be comprised of two key subbranches: one containing C++ code that can be compiled into a couple of different libs and a second branch that contains mex files. When I say, mex file I specifically mean a Matlab executable that can be compiled using mex. I'd like to have all of the C++ libraries built first and then all of the mex files second. The problem is that I don't know how to tell automake to switch to using the mex compiler as opposed to g++. This includes setting the options I want, etc. I looked into resetting the CC, CPP, etc... flags, but that seems shady. Even when I tried that, mex bailed b/c of unrecognized options that automake is throwing at it. Is there a clean way to accomplish what I am trying do? If not, does anyone have any ideas on possible ways around this? Bear with me, I am new to automake and am still learning :o) Any advice would be greatly appreciated! Thanks in advance! Jason -- View this message in context: http://www.nabble.com/Compiling-project-requiring-w--source-requiring-different-compilers-tp15026216p15026216.html Sent from the Gnu - Automake - General mailing list archive at Nabble.com.
Re: linking source files from a different directory macro
Hello Jason, * Jason Roscoe wrote on Tue, Jan 22, 2008 at 01:17:55PM CET: Ralf Wildenhues wrote: You can use AC_CONFIG_LINKS from Autoconf: http://www.gnu.org/software/autoconf/manual/html_node/Configuration-Links.html http://www.gnu.org/software/automake/manual/html_node/Optional.html [...] You can use AC_CONFIG_LINKS([common/tester.c], [test/tester.c]) [...] I also saw AC_CONFIG_LINKS but I wasn't sure it would be appropriate for what I was trying to do. I'll have a look at it again. One other thing is that I would like the links to be removed during a 'make clean' step, e.g.. Do you know offhand if AC_CONFIG_LINKS will setup any rules to remove the links? The second link I provided above documents this. Cheers, Ralf
Re: GNU Automake 1.10.1 released
Hello Tim, * Tim Rice wrote on Tue, Jan 22, 2008 at 06:57:59PM CET: On Tue, 22 Jan 2008, Ralf Wildenhues wrote: I'm pleased to announce the release of Automake 1.10.1. Any reason this never made it in? http://lists.gnu.org/archive/html/bug-automake/2005-10/msg00016.html Dunno, don't remember seeing that before. Let's take a look: | --- automake-1.9.6/lib/am/subdirs.am.old2005-05-14 13:21:06.0 -0700 | +++ automake-1.9.6/lib/am/subdirs.am2005-10-27 21:04:01.460314004 -0700 | @@ -93,7 +93,7 @@ | esac; \ | rev=''; for subdir in $$list; do \ | if test $$subdir = .; then :; else \ | - rev=$$subdir $$rev; \ | + test -d $$subdirrev=$$subdir $$rev; \ | fi; \ | done; \ | ## Always do `.' last. 0) It needs a s/ [ ]*/ /g. 1) With some BSD make's, test $CONDITION $ACTION makes `make' stop when the condition is false. Solution is to use test ! $CONDITION || $ACTION 2) If the above is applied, a make clean will not fail if some subdirectories are not present (though a subsequent `make all' will). I'm not sure if this is a problem; I certainly don't think subdirectories get lost all that often, but I have a habit of using `make clean' after $vcs update and similar operations to find out if everything is still ok. Have you encountered this in packages other than Libtool? Asking because Libtool HEAD has this fixed. Cheers, and thanks, Ralf
Re: GNU Automake 1.10.1 released
Hello Ralf, On Tue, 22 Jan 2008, Ralf Wildenhues wrote: Hello Tim, * Tim Rice wrote on Tue, Jan 22, 2008 at 06:57:59PM CET: On Tue, 22 Jan 2008, Ralf Wildenhues wrote: I'm pleased to announce the release of Automake 1.10.1. Any reason this never made it in? http://lists.gnu.org/archive/html/bug-automake/2005-10/msg00016.html Dunno, don't remember seeing that before. Let's take a look: | --- automake-1.9.6/lib/am/subdirs.am.old2005-05-14 13:21:06.0 -0700 | +++ automake-1.9.6/lib/am/subdirs.am2005-10-27 21:04:01.460314004 -0700 | @@ -93,7 +93,7 @@ | esac; \ | rev=''; for subdir in $$list; do \ | if test $$subdir = .; then :; else \ | - rev=$$subdir $$rev; \ | + test -d $$subdirrev=$$subdir $$rev; \ | fi; \ | done; \ | ## Always do `.' last. 0) It needs a s/ [ ]*/ /g. 1) With some BSD make's, test $CONDITION $ACTION makes `make' stop when the condition is false. Solution is to use test ! $CONDITION || $ACTION Or, --- lib/am/subdirs.am.old 2008-01-21 14:11:41.0 -0800 +++ lib/am/subdirs.am 2008-01-22 15:16:05.207832004 -0800 @@ -91,7 +91,9 @@ esac; \ rev=''; for subdir in $$list; do \ if test $$subdir = .; then :; else \ - rev=$$subdir $$rev; \ + if test -d $$subdir; then \ + rev=$$subdir $$rev; \ + fi; \ fi; \ done; \ ## Always do `.' last. 2) If the above is applied, a make clean will not fail if some subdirectories are not present (though a subsequent `make all' will). I'm not sure if this is a problem; I certainly don't think subdirectories get lost all that often, but I have a habit of using `make clean' after $vcs update and similar operations to find out if everything is still ok. Have you encountered this in packages other than Libtool? Asking because Libtool HEAD has this fixed. I think I remember other packages having that problem but I've been patching automake for so long I don't have a clue which ones. If I remember correctly, it was when I did not use some feature that was in its own subdir. Cheers, and thanks, Ralf Thanks for reviewing it. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
