* Paul Eggert wrote on Wed, Dec 01, 2004 at 09:33:25PM CET:
Steven G. Johnson [EMAIL PROTECTED] writes:
(Which begs the question: shouldn't AC_PROG_CC_STDC be renamed to
AC_PROG_CC_C89, for consistency?)
Yes, and AC_PROG_CC_STDC should refer to the best (typically, latest)
C standard.
Bob Friesenhahn wrote:
On Wed, 1 Dec 2004, Eric PAIRE wrote:
It this solution is so obvious, I don't understand why autotools
developers have not already set up a tool which automatically removes
the files generated by the autotools (perhaps this tool exists and I
don't know about).
It is
Hi,
On Wed, Dec 01, 2004 at 11:35:58PM +0100, Alexandre Duret-Lutz wrote:
Speaking of manuals, the FAQ section of the Automake manual also
have a node called CVS and listing pros, cons, and workarounds.
I have noticed a typo there, see the patch below.
As usual, thank you very much for nicely
Hi all,
We had the same problems, so for the (re)bootstrapping of our project
we now use our own 'bootstrap' script (which is included in both CVS
and the source package):
---
#!/bin/sh
echo ---removing generated files---
# products from ./configure and make
if test -f Makefile ; then
# touch
Bob Proulx wrote:
Henrique de Moraes Holschuh wrote:
Add a run-this-on-checkout script and proper rules to the makefiles to run
the autotools sequence if the autotools files are not yet available.
Shouldn't 'autoreconf' be the right answer to regenerate all of the
autotools files after a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Eggert [EMAIL PROTECTED] writes:
Roger Leigh [EMAIL PROTECTED] writes:
One change I've made is added arguments to AC_PROG_CC_C89,
AC_PROG_CC_C89 and AC_PROG_CC_STDC to allow custom code to run on
success or failure, to e.g. abort configure
Roger Leigh wrote:
I'd rather avoid this complexity. Isn't it easy enough to abort based
on the value of ac_cv_prog_cc_c89 (or whatever)?
Yes, but I didn't know if users were allowed access to those
internals. I've reverted this (but kept it for internal use).
From a plain-old-user's point of
Ralf Wildenhues [EMAIL PROTECTED] writes:
This worries me to some extent. While C99 is mostly backwards
compatible with C89, it has removed some deprecated things such as
functions return implicit int,
implicit function declaration.
In practice this shouldn't be much of a problem, since
Kevin P. Fleming [EMAIL PROTECTED] writes:
The risk would certainly be there for people who enable -Werror (or
the equivalent for non-gcc compilers) early in their configure script
as part of their maintainer mode (like I do).
Can you test Autoconf with 'gcc -std=c99 -pedantic-errors
Paul Eggert wrote:
Can you test Autoconf with 'gcc -std=c99 -pedantic-errors -Werror'?
That might catch some of the problems we're worried about.
I don't currently use C99-isms in my projects, because I didn't have a
clean way to test for compatibility in my distributions. That's why I'm
glad to
Kevin P. Fleming [EMAIL PROTECTED] writes:
From a plain-old-user's point of view, I'd much rather see Roger's
original version. I don't want to rely on undocumented autoconf
internals any more than I have to.
Part of the motivation for keeping that stuff hidden is that we don't
want people
Paul Eggert wrote:
Part of the motivation for keeping that stuff hidden is that we don't
want people to switch based on whether our macro thinks the compiler
is C99 or C89 or not. They should switch based on the
particular feature that they need.
Hmm... I see your point, but wouldn't that then
Roger Leigh [EMAIL PROTECTED] writes:
+ for (unsigned int i = 0; *(text+i) != '\0'; ++i);
Please put a continue before the ;, to forestall warnings from
some compilers.
+# GCC-std=gnu99 -std=c99 -std=iso9899:1999
+# AIX-qlanglvl=extc99 -qlanglvl=stdc99
+#
On Thu, 2 Dec 2004, Kevin P. Fleming wrote:
Paul Eggert wrote:
Can you test Autoconf with 'gcc -std=c99 -pedantic-errors -Werror'?
That might catch some of the problems we're worried about.
I don't currently use C99-isms in my projects, because I didn't have a clean
way to test for compatibility
On Thu, Dec 02, 2004 at 10:54:36AM -0800, Paul Eggert wrote:
Can you test Autoconf with 'gcc -std=c99 -pedantic-errors -Werror'?
That might catch some of the problems we're worried about.
Very interesting. I just tried that on the meaty configure script of net-snmp.
$ gcc -v
Reading specs
Kevin P. Fleming [EMAIL PROTECTED] writes:
Can you test Autoconf with 'gcc -std=c99 -pedantic-errors -Werror'?
That might catch some of the problems we're worried about.
I don't currently use C99-isms in my projects, because I didn't have a
clean way to test for compatibility in my
On Thu, 2 Dec 2004, Paul Eggert wrote:
That's why I'm glad to see this macro (and related changes) moving
ahead, so I can feel free to start using C99 features without worry
(other than users may be forced to upgrade their systems to support
C99 if they have old compilers, but at least they'll
Noah Misch [EMAIL PROTECTED] writes:
configure:18743: warning: overflow in implicit constant conversion
That one is easy to fix; I installed the patch enclosed below.
The other problems are harder. Basically, the problem is that
Autoconf needs a way to tell whether a function exists, without
$ autoscan
autom4te: configure.ac: no such file or directory
autoscan: /usr/bin/autom4te failed with exit status: 1
This is a puzzling message, since the purpose of autoscan, as I
understand it, is to produce a file which, if blessed by me, becomes
configure.ac. So why would it complain that
Sorry to interrupt your normally scheduled programming...
I've read most of the documentation or tutorials I could find, but I'm
afraid much of it went right past me. Most of the tutorials seem to focus
on very straightforward examples, e.g. 'hello world' stuff. I have a small
project, and I
Ross Boylan [EMAIL PROTECTED] writes:
Does this just indicate that autoscan does additional stuff for people
who have configure.ac, or is something wrong?
$ autoscan --version
autoscan (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.
Running on Debian GNU/Linux. It
Le 2 déc. 04, à 21:45, Paul Eggert a écrit :
That's why I'm glad to see this macro (and related changes) moving
ahead, so I can feel free to start using C99 features without worry
(other than users may be forced to upgrade their systems to support
C99 if they have old compilers, but at least
-Original Message-
From: [EMAIL PROTECTED] [mailto:autoconf-
[EMAIL PROTECTED] On Behalf Of Ben Pfaff
Sent: vendredi 3 décembre 2004 00:34
To: [EMAIL PROTECTED]
Subject: Re: Problems running autoscan
Ross Boylan [EMAIL PROTECTED] writes:
Does this just indicate that autoscan
-Original Message-
From: [EMAIL PROTECTED] [mailto:autoconf-
[EMAIL PROTECTED] On Behalf Of Robert Lowe
Sent: vendredi 3 décembre 2004 00:31
To: [EMAIL PROTECTED]
Subject: A newbie asks...
1. POSIX threads
Is this solved as easily as adding the acx_pthread macro in
Hello,
I don't have enough experience to answer all your question, but I'll try
to provide one suggestion:
On Thu, Dec 02, 2004 at 05:31:15PM -0600, Robert Lowe wrote:
2. A header file which seems to be in different places on some platforms
(net/ethernet.h, sys/ethernet.h, and perhaps
* Paul Eggert wrote on Thu, Dec 02, 2004 at 09:53:52PM CET:
Personally, I don't advocate assuming C99 just yet -- only one C99
compiler exists right now, as far as I know, and it's not free -- but
other people might reasonably disagree and Autoconf can cater to them
too. Also, people can
26 matches
Mail list logo
