Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> This strikes me as a completely arbitrary set of changes in
>> long-established behavior. People who want to turn off optimization
>> already know how to do it, and people who want asserts already know
> How do you do it? CFLAGS="" configure?
I'd do CFLAGS="-O0" configure, but the other might work too. I think at
one point the autoconf code treated empty CFLAGS as being unset, but we
might have fixed that.
>> how to do that. Eliminating the functional difference between these
>> --enable options isn't a step forward.
> I was looking for something that would be a middle ground, and I thought
> a super-debug binary might to it. I do think we should consider -g3 for
> gcc. I didn't know it existed, and it does seem nice.
The argument in favor of adding -g by default for gcc is based in very
large part on the assumption that it doesn't cost any performance.
Changing --enable-debug so that it *does* cost performance (by
suppressing optimization) isn't a "middle ground"; it turns the switch
into something useful only for developers, and guarantees that no binary
used in the field will ever have debug info. I don't think we want that.
My experience is that debugging optimized code is not as hard as you
make it out to be --- I normally build with -O1 or -O2, because -O0 code
has awful performance on HPPA. Only rarely will I recompile -O0 because
I can't follow what's happening in a particular section of code.
I'm not sure about -g3; how much does it bloat the executable? Does it
work in every version of gcc?
regards, tom lane