| 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
| 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 |