From: | Junwang Zhao <zhjwpku(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [meson] expose buildtype debug/optimization info to pg_config |
Date: | 2023-12-22 09:44:20 |
Message-ID: | CAEG8a3Jh62+r-ve5N7oSEserp4DSMvD5Tqm3rdYABK+wJOTSyQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Fri, Dec 15, 2023 at 10:20 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2023-12-14 17:24:58 +0800, Junwang Zhao wrote:
> > On Thu, Dec 14, 2023 at 4:50 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> > >
> > > On 12.12.23 11:40, Junwang Zhao wrote:
> > > > build system using configure set VAL_CFLAGS with debug and
> > > > optimization flags, so pg_config will show these infos. Some
> > > > extensions depend on the mechanism.
> > > >
> > > > This patch exposes these flags with a typo fixed together.
> > >
> > > I have committed the typo fix.
> > >
> > > But I would like to learn more about the requirements of extensions in
> > > this area. This seems a bit suspicious to me.
> >
> > This is what I found when building citus against an installation
> > of meson debug build pg instance, since the CFLAGS doesn't
> > contain -g flag, the binary doesn't include the debug information,
> > which is different behavior from configure building system.
>
> Hm. I'm not sure it's the right call to make extensions build the same way as
> the main postgres install with regard to optimization and debug info. So I
> feel a bit hesitant around generating -g and particularly -Ox. But it's
> historically what we've done...
>
> If we want to do so, I think this should not check buildtype, but debug.
I'm confused which *debug* do you mean, can you be more specific?
>
>
> > Another issue I found is that some C++
> > extensions(ajust/parquet_fdw for example) don't build against
> > the meson generated pgxs.mk, since it doesn't set the CXX
> > command. CXX is only set when llvm option is enabled, which
> > is different from old building system.
>
> I wanted to skip the C++ tests when we don't need C++, because it makes
> configure take longer. But I could be convinced that we should always at least
> determine the C++ compiler for Makefile.global.
The first idea that came to my mind is using the *project* command
to set [`c`, `cpp`], but this might be a little bit confusing for somebody.
Then I tried another way by adding a 'pgxscpp' option to let the user
choose whether he will set the C++ compiler for Makefile.global.
It works but may not be an ideal way, see the attached.
>
> Greetings,
>
> Andres Freund
--
Regards
Junwang Zhao
Attachment | Content-Type | Size |
---|---|---|
0001-PGXS-determine-C-compiler-for-Makefile.global.patch | application/octet-stream | 1.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2023-12-22 09:48:06 | Re: Optimization outcome depends on the index order |
Previous Message | Zhijie Hou (Fujitsu) | 2023-12-22 09:41:13 | RE: Synchronizing slots from primary to standby |