Howdy all!
I have a configure script which needs to know whether it is dealing
with the f95 distributed with gcc-4.x, or the g95, which is apparently
an independent project, which handles slightly differently.
In both cases ac_cv_fc_compiler_gnu is set to yes.
At the moment I am distinguishing
Hi Ed,
* Ed Hartnett wrote on Mon, Feb 06, 2006 at 04:42:01PM CET:
I have a configure script which needs to know whether it is dealing
with the f95 distributed with gcc-4.x, or the g95, which is apparently
an independent project, which handles slightly differently.
What are the differences
Dear all,
is there a macro to enable (sp)lint checking within autoconf/automake?
Kind Regards
Thomas Roesner
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
You know, I've recently finished reading the manuals for m4, libtool,
autoconf, and automake. After 1000 pages of reading, I was frustrated to
walk away knowing very little more than I started with. I believe this
is primarily due to the lack of examples and background context in the
explanations
ill second that.
autoconf is that bad. i havent written any m4 scripts though. and
couldnt get automake to work.
matt
On Mon, 6 Feb 2006, John Calcote wrote:
You know, I've recently finished reading the manuals for m4, libtool,
autoconf, and automake. After 1000 pages of reading, I was
Generally, when I build with the DEBUG macro defined, it's because I want to
step through a portion of my code with the debugger. However, I've noticed that
using AC_PROG_CC sets CFLAGS to -g -O2 on GCC - and tries to use similar
options on other compilers.
I really like the use of this
John Calcote wrote:
Generally, when I build with the DEBUG macro defined, it's because I want to step through a portion of my code with the debugger. However, I've noticed that using AC_PROG_CC sets CFLAGS to -g -O2 on GCC - and tries to use similar options on other compilers.
I really like
John Calcote wrote:
Generally, when I build with the DEBUG macro defined, it's because I want to
step through a portion of my code with the debugger. However, I've noticed
that using AC_PROG_CC sets CFLAGS to -g -O2 on GCC - and tries to use
similar options on other compilers.
-g -O2 is
John Calcote [EMAIL PROTECTED] writes:
My question: Anyone know of a good idiom for managing optimization flags -
including disabling the obligatory -O2 placed in CFLAGS by AC_PROG_CC?
.../configure CFLAGS=-g
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH,
My question: Anyone know of a good idiom for managing optimization flags -
including disabling the obligatory -O2 placed in CFLAGS by AC_PROG_CC?
.../configure CFLAGS=-g
This sucks too - it means one has to do separate configure runs for
debug, production, profiled, etc. builds
It would be
Andreas Schwab wrote:
John Calcote [EMAIL PROTECTED] writes:
My question: Anyone know of a good idiom for managing optimization flags -
including disabling the obligatory -O2 placed in CFLAGS by AC_PROG_CC?
.../configure CFLAGS=-g
That may be a clean approach, but running configure is slow
On Tue, 7 Feb 2006, Harlan Stenn wrote:
My question: Anyone know of a good idiom for managing optimization flags -
including disabling the obligatory -O2 placed in CFLAGS by AC_PROG_CC?
.../configure CFLAGS=-g
This sucks too - it means one has to do separate configure runs for
debug,
If it sucks, it seems to be exceedingly minor suckage to me since you
can have as many build trees as you want using one source tree.
Sometimes it is easier to go with the flow.
You have clearly not spent much time with large auto*-based build
systems.
I'm talking about software packages
On Tue, 7 Feb 2006, Harlan Stenn wrote:
If it sucks, it seems to be exceedingly minor suckage to me since you
can have as many build trees as you want using one source tree.
Sometimes it is easier to go with the flow.
You have clearly not spent much time with large auto*-based build
systems.
John Calcote wrote:
Generally, when I build with the DEBUG macro defined, it's because I want to step through a portion of my code with the debugger. However, I've noticed that using AC_PROG_CC sets CFLAGS to -g -O2 on GCC - and tries to use similar options on other compilers.
I really like
On Tue, Feb 07, 2006 at 01:37:14AM +0100, Andreas Schwab wrote:
John Calcote [EMAIL PROTECTED] writes:
My question: Anyone know of a good idiom for managing optimization flags -
including disabling the obligatory -O2 placed in CFLAGS by AC_PROG_CC?
.../configure CFLAGS=-g
Just out of
.../configure CFLAGS=-g
Just out of curiosity, is this different than 'CFLAGS=-g ./configure
...'? I do this all the time and wonder if your way is somehow better.
With configure CFLAGS=-g, configure knows you are overriding CFLAGS and
will put that information into config.status.
If you
Bob Rossi wrote:
Just out of curiosity, is this different than 'CFLAGS=-g ./configure
...'? I do this all the time and wonder if your way is somehow better.
If you happen to run into a package using older 2.13 autoconf, you have
to use the CFLAGS=foo ./configure. Otherwise you get this:
$
Harlan Stenn wrote:
With configure CFLAGS=-g, configure knows you are overriding CFLAGS and
will put that information into config.status.
If you use CFLAGS=-g ./configure, then configure doesn't see that you
have overridden CFLAGS.
Or something like that.
No, they should result in
$ diff -u {build1,build2}/Makefile
As you can see the Makefiles are identical and the config.statuses
differ by only one insignificant whitespace.
Cool!
That didn't used to be the case, as I remember from the docs.
I do remember (perhaps incorrectly) that the difference was apparent
when
Harlan Stenn wrote:
That didn't used to be the case, as I remember from the docs.
I do remember (perhaps incorrectly) that the difference was apparent
when running config.status --recheck.
I am sure there is more to it that I am not aware of. Otherwise, there
would be no controversy.
* Brian Dessent wrote on Tue, Feb 07, 2006 at 05:09:19AM CET:
Harlan Stenn wrote:
That didn't used to be the case, as I remember from the docs.
I do remember (perhaps incorrectly) that the difference was apparent
when running config.status --recheck.
I am sure there is more to it
22 matches
Mail list logo
