Re: Still a few flaws in configure's default CFLAGS selection

Bruce Momjian wrote:
> Jan Wieck wrote:
>> > In fact, even though I was debugging the backend regularly, I removed -g
>> > and added it only when I wanted to debug.
>> >
>>
>> It did somethimes in the past proove to be good luck to have symbols in
>> a core file accidentially. If you want to find them in an arbitrary out
>> of the box installation, they have to be in the default configuration.
>> That they cannot be there if a non-gcc does not optimize the code then,
>> sure. But I don't really see the confusion you're talking about. Nor do
>> I see the importance of link-time when setting up a production system
>> from sources. Do not mix up developer usage with DBA usage. You can ask
>> a developer to use "--disable-debug", and when he complains about slow
>> compiles it's still time to tell him. But if you expect a DBA to
>> configure "--enable-debug" you will get core files that are plain
>> useless and it's too late.
>>
>> What I would like to maintain is the best possible support capability
>> (finding symbols wherever possible to do the aftermath of a crashed
>> backend), while providing the best possible performance - with
>> performance having priority. That this leads to different options used
>> on different platforms and compilers, so be it.
>
> This leaves us with "--enable-debug" for non-gcc compilers, and adding
> "--disable-debug" for gcc compilers.
>
> Right now configure --help has:
>
> --enable-debug build with debugging symbols (-g)
>
> If people want to add --disable-debug, and document which is gcc and
> non-gcc, that is fine with me.
>
> Also, usually, you don't want to run the debugger on optimized code
> unless you are debugging a compiler issue, so maybe we should call it
> --debugging-symbols and --no-debugging-symbols to make it clear what the
> option does.

I never "want" to run any debugger, I am sometimes "forced" to do so and
then the more symbols I have the better. Debugging optimized code can
lead to some confusion as the optimizer is allowed to reorder code
execution or keep variables in registers instead of on the stack and
thus, the flow of instructions is not in sync with the sourcecode, what
makes it kinda hard sometimes to set breakpoints or to see what
statements actually have NOT been executed already when looking at a file.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #