Re: convert CI CompilerWarnings job to meson

From: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: convert CI CompilerWarnings job to meson
Date: 2026-09-25 10:58:43
Message-ID: CAN55FZ27gvs6AkO0muDLq0RV8E8JRh1b=ctZpqeDg_jTWZ1Usw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thu, 24 Sept 2026 at 18:12, Peter Eisentraut <peter(at)eisentraut(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2026-09-25 11:00:02 Re: Remove invalid SS2/SS3 handling from EUC-KR routines
Previous Message Ashutosh Bapat 2026-09-25 10:57:38 Re: [PATCH] Two remaining shmem attachment issues in single-user mode