Re: Prefer AM_CPPFLAGS to @CPPFLAGS@
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Stepan Kasal on 6/11/2007 4:47 AM: Hello Ralf, On Sun, Jun 10, 2007 at 09:13:14AM +0200, Ralf Wildenhues wrote: -CPPFLAGS = -DDATADIR='$(datadir)' @@CPPFLAGS@@ +AM_CPPFLAGS = -DDATADIR='$(datadir)' Why not show both (the non-Automake case is useful and conveys additional information)? A nice idea, but: It would make the node too complex. The node 19.5 How Do I `#define' Installation Directories? is in the FAQ section, so people might expect it is short. True, but AM_CPPFLAGS is not provided by autoconf, and autoconf can be run independently of automake. I think we should either provide both examples, or at least provide a clear disclaimer that this example only works if you also use Automake, along with a pointer to somewhere else in the manual on how to do it when avoiding automake. - -- 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 iD8DBQFGe8Zs84KuGfSFAYARAix5AJ4iW07MUdIG2SwimtBmspn7qUMUwACgo1oH DL857yi2Lxir1G7yIEKDo3g= =I/DA -END PGP SIGNATURE-
Re: Binary Version for Mac OS X?
On Thu, 21 Jun 2007, John W. Eaton wrote: On 21-Jun-2007, Bob Friesenhahn wrote: | You are correct that a strict interpretation of GPL v2 does not allow | GPLed software to be installed using anything other than an an | open-sourced installation program which is itself licenced for | re-distribution under a no more restrictive license than GPL. Really? Even if the installer is not linked with the GPLed program that is installing? Why? I thought the GPL covered derivative works. How would an installer program be a derivative work of the program it installs? it's not (they're reinterpreting the facts to suit their own biases). Looking over this week's thread, Friesenhahn appears to be the winner in the troll contest. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Binary Version for Mac OS X?
herb wrote: Would it break any rules, such as the fact that the Mac OS X Installer program is proprietary software? Even though Installer is proprietary software, the package is not software at all, and installer is just opening it. Or is there not allowed to be any proprietary software in the equation at all? Anyone who makes an argument that this is not allowed needs to explain why it's okay to place GNU software onto an NTFS disk partition. The GPL has nothing to say about the data formats you use to store the software. An OS X .pkg file isn't even opaque, except artificially in Finder: it's just a specially formatted directory structure. The packaged files are in my.pkg/Contents/Resources, IIRC. What _does_ matter, however, is that your .pkg file needs to include a copy of the sources you used to build the binary, or at least some kind of link or contact information for obtaining the sources. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
[GNU Autoconf-2.59] : testsuite: 10
## - ##failed
## GNU Autoconf 2.59 test suite. ##
## - ##
testsuite: command line was:
$ ./testsuite
## --- ##
## ChangeLogs. ##
## --- ##
testsuite: ../ChangeLog:
| 2003-11-06 Akim Demaille [EMAIL PROTECTED]
|
| Version 2.59.
|
| 2003-11-05 Alexandre Duret-Lutz [EMAIL PROTECTED]
|
| * lib/autoconf/status.m4 (_AC_SRCPATHS): Fix use of AS_SET_CATFILE
| so that ac_abs_builddir, ac_abs_top_builddir, ac_abs_srcdir,
| and ac_abs_top_srcdir are absolute paths.
| * lib/m4sugar/m4sh.m4 (AS_SET_CATFILE): Remove misleading comment.
## - ##
## Platform. ##
## - ##
hostname = Salehh
uname -m = i686
uname -r = 1.0.11(0.46/3/2)
uname -s = MINGW32_NT-5.1
uname -v = 2004-04-30 18:55
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /c/work/autoconf-2.59/tests
PATH: /c/work/autoconf-2.59
PATH: /mingw/bin
PATH: /bin
PATH: /c/Program Files/TeXLive/bin/win32
PATH: /c/Perl/bin
PATH: /c/WINDOWS/system32
PATH: /c/WINDOWS
PATH: /c/WINDOWS/System32/Wbem
PATH: /c/matlab6p5/bin/win32
PATH: /c/MSSQL/BINN
PATH: /c/php
PATH: /c/Program Files/Common Files/Autodesk Shared
PATH: /c/Program Files/MySQL/MySQL Server 5.0/bin
PATH: /c/Program Files/Microsoft Visual Studio/VC98/bin
PATH: /c/utils
PATH: /c/PFWSCH
PATH: /c/PFW
testsuite: atconfig:
| # Configurable variable values for building test suites.
| # Generated by ./config.status.
| # Copyright (C) 2000, 2001, 2003 Free Software Foundation, Inc.
|
| # The test suite will define top_srcdir=/../.. etc.
| at_testdir='tests'
| abs_builddir='/c/work/autoconf-2.59/tests'
| at_srcdir='.'
| abs_srcdir='/c/work/autoconf-2.59/tests'
| at_top_srcdir='..'
| abs_top_srcdir='/c/work/autoconf-2.59/tests/..'
| at_top_builddir='../'
| abs_top_builddir='/c/work/autoconf-2.59/tests/../.'
|
| AUTOTEST_PATH='tests'
|
| SHELL=${CONFIG_SHELL-'/bin/sh'}
testsuite: atlocal:
| # -*- shell-script -*-
| # tests/atlocal. Generated from atlocal.in by configure.
| # Configurable variable values for Autoconf test suite.
| # Copyright 2000, 2001 Free Software Foundation, Inc.
|
| # We need Perl.
| PERL='/bin/perl'
## ##
## Tested programs. ##
## ##
local.at:370: /c/work/autoconf-2.59/tests/autom4te --version
autom4te (GNU Autoconf) 2.59
Written by Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
local.at:370: /c/work/autoconf-2.59/tests/autoconf --version
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
local.at:370: /c/work/autoconf-2.59/tests/autoheader --version
autoheader (GNU Autoconf) 2.59
Written by Roland McGrath and Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
local.at:370: /c/work/autoconf-2.59/tests/autoupdate --version
autoupdate (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
local.at:370: /c/work/autoconf-2.59/tests/autoreconf --version
autoreconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
local.at:370: /c/work/autoconf-2.59/tests/ifnames --version
ifnames (GNU Autoconf) 2.59
Written by David J. MacKenzie and Paul Eggert.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
## -- ##
## Running the tests. ##
## -- ##
testsuite: starting at: Fri Jun 22 12:08:50 WCAST 2007
1. Syntax of the shell scripts (tools.at:47): ok (0m1.105s 0m1.920s)
2. Syntax of the Perl scripts (tools.at:92): ok (0m1.588s 0m2.755s)
3. autom4te cache (tools.at:118): ok (0m5.472s 0m7.882s)
4. autoconf --trace: user macros (tools.at:155): ok (0m12.751s 0m16.847s)
5. autoconf --trace: builtins (tools.at:242): ok (0m9.648s 0m11.506s)
6. autoconf: forbidden tokens, basic (tools.at:273): ok (0m4.104s 0m5.536s)
7. autoconf: forbidden tokens, exceptions (tools.at:301):
Re: Autoconf and Solaris Lint
Ralf Wildenhues wrote:
* Jason Curl wrote on Wed, Jun 20, 2007 at 11:55:54PM CEST:
I've searched in vain on the Web how I might run configure to use Solaris'
'lint' program. It appears that their 'lint' is very much like a compiler
where it produces objects that can be linked together to form a final
result.
The command below doesn't work.
CC=lint ./configure --host=sparc-sun-solaris2.10
I'd be interested to see which tests come out wrong with the above.
Could you take a look at config.log and search for obviously wrong
results?
I've also tried something similar to what you did
./configure CC=lint LD=/usr/ccs/bin/ld cross_compile=yes
and the results are:
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
Looking at config.log I see:
configure:2756: lint --version 5
lint: unknown option: -
usage: lint [ options] files. Use 'lint -flags' for details
configure:2759: $? = 1
configure:2766: lint -v 5
usage: lint [ options] files. Use 'lint -flags' for details
configure:2769: $? = 1
configure:2776: lint -V 5
lint: Sun C 5.8 2005/10/13
usage: lint [ options] files. Use 'lint -flags' for details
configure:2779: $? = 1
configure:2802: checking for C compiler default output file name
configure:2829: lintconftest.c 5
configure:2832: $? = 0
configure:2870: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME My Program
| #define PACKAGE_TARNAME MyProg
| #define PACKAGE_VERSION 0.4.2.2
| #define PACKAGE_STRING My Program 0.4.2.2
| #define PACKAGE_BUGREPORT [EMAIL PROTECTED]
| #define PACKAGE MYPROG
| #define VERSION 0.4.2.2
| #define _GNU_SOURCE 1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2877: error: C compiler cannot create executables
See `config.log' for more details.
So does it appear autoconf relies on the compiler invoking LD
automatically?
Next, it would help to see how this fares:
./configure
env CC=lint make -e
but of course this is a bit more cumbersome to use.
To start, it depends a lot on the compile configure found when it
started. There's a lot of options that are GNU specific that 'lint'
doesn't understand. I've tried it twice, with GCC in the path, and without.
with:
ganymede:jcurl:LX2005-0.4.2.2$ CC=lint gmake -e
...
lint -DHAVE_CONFIG_H -I.-DSYSCONFDIR=\/usr/local/etc\ -O2 -Wall
-MT console.o -MD -MP -MF .deps/console.Tpo -c -o console.o console.c
lint: unknown option: M
lint: unknown option: T
lint: unknown option: M
lint: unknown option: M
lint: file with unknown suffix ignored: console.o
lint: file with unknown suffix ignored: .deps/console.Tpo
error: -D option argument not an identifier
lint: errors in console.c; no output created
without:
ganymede:jcurl:LX2005-0.4.2.2$ CC=lint dmake -e
source='console.c' object='console.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../../config/depcomp \
lint -DHAVE_CONFIG_H -I. -DSYSCONFDIR=\/usr/local/etc\ -g -c
console.c
...
/usr/ccs/bin/ar cru liblogger.a console.o file.o output.o profile.o
queue.o serial.o strfunc.o tcpip.o ipcproto.o dbgmsg.o
appframework.o confopts.o timersub.o timeradd.o getline.o strnlen.o
ar: cannot open console.o
No such file or directory
It gets further, but because I'm building a static library (that I will
later 'libtoolise') it fails at the part it wants to link with 'ar'. I
can override that with
ganymede:jcurl:LX2005-0.4.2.2$ CC=lint AR=lint ARFLAGS='' dmake -e
...
lint liblogger.a console.o file.o output.o profile.o queue.o
serial.o strfunc.o tcpip.o ipcproto.o dbgmsg.o appframework.o
confopts.o timersub.o timeradd.o getline.o strnlen.o
lint: file with unknown suffix ignored: liblogger.a
lint: file with unknown suffix ignored: console.o
...
Reading the manual page for 'lint' it has the following extensions:
Arguments whose names end with .c are taken to be C source
files; arguments ending in .i are taken to be preprocessor
output files (produced with the -P option to the compiler).
Arguments whose names end with .ln are taken to be the
result of an earlier invocation of lint with either the -C,
-c, or the -o option used. The .ln files are analogous to .o
(object) files that are produced by the cc(1) command when
given a .c file as input. Files with other suffixes are
warned about and ignored.
When compiling libraries, we'd probably want to do something a little
different (again from the manpage):
lint takes all the .c, .i, .ln, and llib-lx.ln (specified by
-lx) files and processes them in their command-line order.
By default, lint appends the standard C lint library (llib-
lc.ln) to the end of the list of files. When the -C or -c
option is used, the .ln
Re: autotest strips trailing whitespace from expected stdout
Hello Mike, * Mike Frysinger wrote on Fri, Jun 22, 2007 at 08:09:10AM CEST: i was converting another project to autotest when i hit a test failure due to trailing whitespace mismatch ... consider this: AT_SETUP(white) AT_CHECK([echo WHITESPACE: ], [0], [dnl WHITESPACE: ]) will result in a test failure as trailing whitespace is stripped from the expected stdout when generating the testsuite file but the command run still produces the trailing whitespace ;( Yes. This is intented, albeit maybe arguable. Quoting `(autoconf.info)Quadrigraphs': | The empty quadrigraph can be used: | | - to mark trailing spaces explicitly | | Trailing spaces are smashed by `autom4te'. This is a feature. So you can use WHITESPACE: @t@ Hope that helps. Cheers, Ralf
Re: CVS Automake fails to make check with CVS Autoconf
[ adding bug-autoconf; this is http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2774 ] Hello Benoit, all, Thanks for the report. * Benoit Sigoure wrote on Sat, Jun 16, 2007 at 08:47:54AM CEST: when running HEAD's make check, I get a failure: + aclocal-1.10a -Werror configure.in:4: error: AC_SUBST: `$1' is not a valid shell variable name configure.in:4: the top level autom4te: /opt/local/bin/gm4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 + exit 1 FAIL: subst.test autoconf/lib/autoconf/general.m4:2042 reads: m4_define([AC_SUBST], [m4_bmatch(m4_bpatsubst([[$1]], [@[EMAIL PROTECTED]), ^m4_defn([m4_re_word])$, [], [AC_FATAL([$0: `$1' is not a valid shell variable name])])dnl [...] (They are all from yesterday's CVS HEAD excepted GNU M4) Hmm. automake/tests/subst.test is from 1996 and has seen trivial changes in 2001 and 2002, and has this comment: # Test that AC_SUBST($1) does something sensible. From Ulrich # Drepper. It is broken by this recent (and very sensible) patch against Autoconf: | 2007-06-12 Noah Misch [EMAIL PROTECTED] | | * lib/autoconf/general.m4 (AC_SUBST): Raise a fatal error if VARIABLE is | not a valid shell variable name. | * tests/mktests.sh (ac_exclude_list): Add AC_ARG_VAR. | * tests/torture.at (AC_SUBST: variable name validation): New test. | Reported by Andreas Schwab. Maybe this test ought to be removed from Automake? I'm a bit afraid the Autoconf change, good as it looks to me, may just happen to break some obscure macro code somewhere -- after all, there is a reason that a test exists. Searching around in the glibc CVS repository lead me nowhere conclusive though. FWIW, the Automake change that installed the test has this rather innocent ChangeLog entry: | Tue Dec 10 00:41:17 1996 Tom Tromey [EMAIL PROTECTED] | | * automake.in (AC_SUBST_PATTERN): Check for alphanumeric variable | names only. Test subst.test. I think mailing lists or similar trails were not used back then, but I did not search for any particular now. Suggestions? Cheers, Ralf
Re: [GNU Autoconf-2.59] : testsuite: 10
Ibrahim Hassan [EMAIL PROTECTED] writes: ## GNU Autoconf 2.59 test suite. ## 2.59 is pretty old. Please try again with 2.61. -AC_CONFIG_FILES([Makefile]) -AC_CONFIG_COMMANDS([default],[[echo $fubar]],[[fubar=$fubar]]) +AC_CONFIG_FILES([Makefile]) +AC_CONFIG_COMMANDS([default],[[echo $fubar]],[[fubar=$fubar]]) That's pretty weird. The old file is identical to the new. Perhaps the test suite is broken, or maybe your utilities?
Re: CVS Automake fails to make check with CVS Autoconf
How about this (untested) patch to Automake? 2007-06-22 Paul Eggert [EMAIL PROTECTED] * tests/subst.test: Port to CVS autoconf. Problem reported by Benoit Sigoure in: http://lists.gnu.org/archive/html/automake-patches/2007-06/msg3.html --- automake/tests/subst.test.~1.5.~2005-05-14 13:28:56.0 -0700 +++ automake/tests/subst.test 2007-06-22 14:34:32.0 -0700 @@ -1,5 +1,5 @@ #! /bin/sh -# Copyright (C) 1996, 2001, 2002 Free Software Foundation, Inc. +# Copyright (C) 1996, 2001, 2002, 2007 Free Software Foundation, Inc. # # This file is part of GNU Automake. # @@ -30,7 +30,9 @@ END : Makefile.am -$ACLOCAL || exit 1 -$AUTOMAKE || exit 1 -grep '^\$1' Makefile.in exit 1 +if $ACLOCAL; then + $AUTOMAKE || exit 1 + grep '^\$1' Makefile.in exit 1 +fi + exit 0
Re: Bug in gnulib-tools prevents bison from bootstrapping
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adding bug-autoconf, this thread started here: http://lists.gnu.org/archive/html/bug-gnulib/2007-06/msg00176.html Other lists can be trimmed in replies. According to Hans Aberg on 6/22/2007 7:37 AM: On 22 Jun 2007, at 14:55, according to Eric Blake: According to Hans Aberg on 6/22/2007 6:13 AM: Autoconf requires the latest m4, but it actually calls gm4 it seems. So I installed the latest M4, which ended up in /usr/local/bin/m4 on my system, and added a soft link /usr/local/bin/gm4 - /usr/local/bin/m4 Then it worked. Autoconf finds a working version of GNU m4 as part of its installation process. On your machine, it must have found that gm4 was the correct name for the GNU m4 that was installed at the time you configured autoconf. Alternatives to your symlink proposal, which are somewhat more kosher for system maintainers, I am not sure the above explanation holds up, because I think I had a /usr/local/bin/m4 long before I had a /usr/local/bin/autoconf, and others on the Bison list experienced the same problem, but could not find its origin. would be either reconfiguring and reinstalling autoconf after you installed the more recent GNU m4, I feel fairly sure I tried that, and it did not help. If you reconfigured autoconf after installing a newer GNU m4, and autoconf did not find the right m4, then that is a bug in autoconf, and should be dealt with there. or using the --program-prefix=g option of m4's configure script to install m4 as gm4. My system has a /usr/bison/m4 and a /usr/bin/gm4, but no /usr/local/bin/gm4, because later version of M4 odes not install it. m4 will install as /usr/local/bin/gm4 if you use the --program-prefix=g option at m4's configure time. So you need to check what exactly autoconf does, like simply trying to find gm4 before trying m4, which would be wrong. The current algorithm is in autoconf's m4/m4.m4: AC_PATH_PROGS([M4], [gm4 gnum4 m4], [m4]) AC_CACHE_CHECK([whether m4 supports accurate traces], ... In other words, during configuration, autoconf finds the first program on your PATH named gm4, gnum4, and then m4, which also meets the minimum requirements of m4 1.4.5 or later. If you have suggestions for a better algorithm, we'd like to know about it. - -- 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 iD8DBQFGfKCs84KuGfSFAYARAiduAKCgXM6cz8V33ZyTQt+4jaOZC6GmNwCgsh9r bFwvko5ON29ob2Z9bZupBM8= =gl7u -END PGP SIGNATURE-
