Re: Patch - Debug builds without optimization - Mailing list pgsql-hackers

From Radosław Smogura
Subject Re: Patch - Debug builds without optimization
Date
Msg-id 62bd6dbd78aa2c47af885faa4b5d6405@mail.softperience.eu
Whole thread Raw
In response to Re: Patch - Debug builds without optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
 On Thu, 16 Jun 2011 16:00:21 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> I disagree with this change.  Debug builds are very useful to have 
>> in
>> production, and you don't want to be running -O0 there.  I have 
>> found
>> that you can use a src/Makefile.custom like this for those times 
>> when you
>> want to debug stuff in a particular set of files:
>
>> CFLAGS := $(patsubst -O2,-O0,$(CFLAGS))
>
>> Then you remove the .o files that you want to debug, and rerun make.
>
> FWIW, I only use Makefile.custom for more-or-less-permanent changes 
> to
> the build behavior of a particular machine.  For one-shot things like
> recompiling some particular file(s) at -O0, it's easier to do this:
>
>     rm foo.o
>     make PROFILE=-O0
>     reinstall postgres executable
>
> The makefiles automatically add PROFILE at the end of CFLAGS, so you 
> can
> inject any compile flag this way --- I think the original intent was 
> to
> use it to add -pg for gprof-enabled builds.  But it's handy for this.
>
> BTW, if you're hacking Postgres code and don't already have a
> "reinstall" script, you need one.  Mine is basically
>
>     pg_ctl stop
>     cd $PGBLDROOT/src/backend
>     make install-bin
>     pg_ctl start
>
>             regards, tom laneThanks,
Actually I do something like above, but good to know "install-bin" target, I fired before "gmake -j5 install".
Regards,Radek


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PATCH: CreateComments: use explicit indexing for ``values''
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade using appname to lock out other users