Re: convert CI CompilerWarnings job to meson - Mailing list pgsql-hackers

From Nazir Bilal Yavuz
Subject Re: convert CI CompilerWarnings job to meson
Date
Msg-id CAN55FZ27gvs6AkO0muDLq0RV8E8JRh1b=ctZpqeDg_jTWZ1Usw@mail.gmail.com
Whole thread
In response to convert CI CompilerWarnings job to meson  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
Hi,

On Thu, 24 Sept 2026 at 18:12, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> This has been an open task in the move from autoconf to meson.  It's
> been discussed a few times here and there across various threads, but
> it's gotten a bit confusing, so I'm starting a fresh thread.
>
> The holdup was that the headerscheck target was not ported to meson.
> This was done a few months ago.

Yes, this was missed, nice.


> So converting the CI job to meson is
> now somewhat straightforward.  Here are some patches.

0001 and 0003 LGTM.


> (I found some existing partial work in public git branches from Andres,
> of which I have integrated a few bits here.)
>
> I've tried to be careful to maintain the scope of each individual build
> step (e.g., what features it enables, what optimization level it uses).

For 0002, the 'mingw warnings (cross compilation)' step has a zlib
dependency (since it is enabled by default) in the autoconf build. It
is disabled in meson, but I think that is correct. I wanted to mention
this nevertheless. Other than this, LGTM.


> One thing we're losing is the sharing of the configure cache between the
> steps (gcc.cache, clang.cache).  There is a way to do that in meson
> (meson-private/coredata.dat), but it's not meant to be used across
> different build directories, and so we would have to restructure some of
> this a bit differently, I think, so I stayed away from that for now.

I didn't know that but current performance looks good to me.


> I've done a few rounds of testing and it all seems quite fast, but
> obviously that depends on caching, time of day, and so on, so more
> testing is welcome.

I had 3 runs, p_* means patched:

+--------+----------+--------+
|        | wo_cache | cache  |
+--------+----------+--------+
| master | 30m      | 3m 30s |
+--------+----------+--------+
| p_1    | 18m      | 4m 10s |
+--------+----------+--------+
| p_2    | 20m      | 4m 30s |
+--------+----------+--------+

These are the most recent results I got. As you said timing varies, I
saw that cached runs on master can take up to 8 minutes.

--
Regards,
Nazir Bilal Yavuz
Microsoft



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [PATCH] Two remaining shmem attachment issues in single-user mode
Next
From: John Naylor
Date:
Subject: Re: Remove invalid SS2/SS3 handling from EUC-KR routines