On Tue, 14 Feb 2006, Andre Caldas wrote:
* The user does not know the version he/she is using is old.
Then the user should just upgrade anyway.
ah. may as well be blunt here: you're stating that the user is ignorant.
--
Thomas E. Dickey
http://invisible-island.net
.../configure CFLAGS=-g
That may be a clean approach, but running configure is slow enough as it
is; re-running it for trivial changes is really aggravating.
You would have to make clean anyway!!
If you need to switch that much between CFLAGS definitions, then maybe
you should have two
.../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.
./config.status --version will not document it.
The recomended way is to use
./configure CFLAGS=-g
Andre Caldas.
I'm talking about software packages that, on hot machines, take 30-45
minutes to do a configure run.
Well you just need to run configure once, when you setup the building
tree!!
You certainly don't know what you are doing. The make command will
not track your compilation flags! You don't
./configure CFLAGS=-g -O0
Now whenever you do a make, the default CFLAGS are -g -O0. To use
-g -O2
temporarily or for a session, then: #export CFLAGS=-g -O2
Or:
make CFLAGS=-g -O2
I prefere this because I will not forget about any garbage CFLAGS
that maybe there when I start doing other
Well, yes, Autoconf had to go the compromise and detect *these* flags
also when they were in the environment. But it only does so for a few
common variables. You have to declare a variable as `precious' if you,
the developer, want another variable recorded; see
info Autoconf 'Setting Output
John Calcote wrote:
My point exactly. The autoconf system should reserve a variable that is NOT
the user. Automake has such a facility - AM_CFLAGS. This variable should be
reserved for configure to add flags to the compiler command line based on
higher-level, user-specified options, such as
* Bob Friesenhahn wrote on Tue, Feb 07, 2006 at 03:07:37AM CET:
On Tue, 7 Feb 2006, Harlan Stenn wrote:
I'm talking about software packages that, on hot machines, take 30-45
minutes to do a configure run.
I assure you that I have spent quite a bit of time watching configure
run. So I
* Ralf Wildenhues wrote on Tue, Feb 07, 2006 at 07:08:37AM CET:
You, the user, can still force variable assignments to be recorded even
for non-precious variables by putting them on the configure command
line:
../source/configure FOO=bar
So the bottom line is that you should always use
Brian,
Thanks for the reply. I get this. I realize that you MAY set CFLAGS on
the command line if you wish - and you should - IF you have special
flags to set on the command line for a specific configuration or build.
My complaint was that the AC_PROG_CC macro just assumes you want -O2
(again -
In one case, you are using valid shell command syntax to set a variable
for a specific run of a script or program (var=value ./program).
In the other case, you are passing a parameter to configure, which then
sets this variable for its own environment as it parses its parameter
list, and then
When you override CFLAGS on the configure command line, you give
configure the opportunity to add more flags to the CFLAGS variable that
are then passed on to make. On the other hand, when you modify CFLAGS on
the make command line, you are overriding all settings provided to the
Makefile by the
Brian,
Thanks for the reply. I get this. I realize that you MAY set CFLAGS on
the command line if you wish - and you should - IF you have special
flags to set on the command line for a specific configuration or build.
My complaint was that the AC_PROG_CC macro just assumes you want -O2
(again -
John Calcote [EMAIL PROTECTED] writes:
When you override CFLAGS on the configure command line, you give
configure the opportunity to add more flags to the CFLAGS variable that
are then passed on to make.
Yes, there are many broken configure scripts out there that do that.
Please don't spread
My point exactly. The autoconf system should reserve a variable that is NOT the
user. Automake has such a facility - AM_CFLAGS. This variable should be
reserved for configure to add flags to the compiler command line based on
higher-level, user-specified options, such as --enable-debug, or
John Calcote wrote:
When you override CFLAGS on the configure command line, you give
configure the opportunity to add more flags to the CFLAGS variable that
are then passed on to make. On the other hand, when you modify CFLAGS on
the make command line, you are overriding all settings provided to
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
33 matches
Mail list logo
