| From: | <korryd(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-patches(at)postgresql(dot)org>, "Neil Conway" <neilc(at)samurai(dot)com>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Bruce Momjian" <bruce(at)momjian(dot)us> |
| Subject: | Re: [pgsql-patches] Patch to avoid gprofprofilingoverwrites |
| Date: | 2007-02-01 15:52:07 |
| Message-ID: | 1170345127.6941.153.camel@sakai.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
> >> What about a "--enable-gprof" (or "--enable-profiling"?) configure
> >> flag? This could add the appropriate compiler flags to CFLAGS, enable
> >> LINUX_PROFILE if on Linux, and enable the "gprof/pid" mkdir().
>
> > That would really only work for GCC, wouldn't it?
>
> Well, yeah, but that's what many of us use anyway. I would envision it
> as adding $(PROFILE) to CFLAGS, and then there would be one place
> to adjust "-pg" to something else for another compiler --- perhaps the
> template files could be given a chance to change PROFILE to something
> else.
I don't feel competent to muck around with configure.in (sorry, I'm not
tying to shirk the work, I've just never had any success in writing
configure/automake/autoconf stuff - I have the "leaping goats" book, but
I need a small meaningful example to start with).
Can someone else volunteer to make this change? And then forward the
patch to me so I can learn something useful about how to change
configure.in without breaking it?
-- Korry
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-02-01 17:53:35 | Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum |
| Previous Message | Tom Lane | 2007-02-01 14:33:15 | Re: [pgsql-patches] Patch to avoid gprof profilingoverwrites |