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

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: Still a few flaws in configure's default CFLAGS selection
Дата
Msg-id 3F9C622F.6000701@Yahoo.com
обсуждение исходный текст
Ответ на Re: Still a few flaws in configure's default CFLAGS selection  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Still a few flaws in configure's default CFLAGS selection  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Tom Lane writes:
>> 
>> > What Peter was advocating in that thread was that we enable -g by
>> > default *when building with gcc*.  I have no problem with that, since
>> > there is (allegedly) no performance penalty for -g with gcc.  However,
>> > the actual present behavior of our configure script is to default to -g
>> > for every compiler, and I think that that is a big mistake.  On most
>> > non-gcc compilers, -g disables optimizations, which is way too high a
>> > price to pay for production use.
>> 
>> You do realize that as of now, -g is the default for gcc?  Was that the
>> intent?
> 
> I was going to ask that myself.  It seems strange to include -g by default ---
> we have --enable-debug, and that should control -g on all platforms.

Could it be that there ought to be a difference between the defaults of 
a devel CVS tree, a BETA tarball and a final "production" release?


Jan

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Question about read interval type in binary format
Следующее
От: "Andrew Dunstan"
Дата:
Сообщение: Re: Call for port reports