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
ftp
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 Va
./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 d
> 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 do
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:
Now before you scream that 2.13 is ancient, it still used in lots of
places for whatever reason. The above example was from running the
toplevel configure scr
.../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.
___
.../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 bu
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
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
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
--wi
"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 s
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 - I
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 co
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 co
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 - 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 alwa
* 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
* 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
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.
> $ 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
whe
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
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:
$
> > .../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 y
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
Jus
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 t
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.
> 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:
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, prod
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 s
> > 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 wo
"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
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 -O
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 t
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 mac
34 matches
Mail list logo
