On Mon, Dec 22, 2025 at 1:24 PM Thomas Munro <[email protected]> wrote: > On Mon, Dec 22, 2025 at 11:48 AM Tom Lane <[email protected]> wrote: > > fairywren's still not happy, though only in the v16 branch: > > > > Could not determine contrib module type for test_cloexec > > at build.pl line 54. > > > > This evidently is because the old MSVC build system doesn't > > recognize > > > > PROGRAM += test_cloexec > > OBJS += $(WIN32RES) test_cloexec.o > > > > Is there a reason for using += not just = here? We could certainly > > modify Mkvcbuild.pm to parse this if we need to, but it looks more > > like a gratuitous difference from everyplace else than a useful > > behavior. > > Yeah. Will drop the + signs. I've also written a patch to enable a > separate "Windows - Server 2022, VS 2019 - Mkvcbuild.pm" CI task > alongside the Meson one in the REL_16_STABLE branch. I had run the > affected branches through CI, but of course 16 switched to Meson so it > wasn't testing the third build system... without that, this is just > too painful. I need to step away for a couple of hours, but more in a > bit...
That revealed another problem: Mkvcbuild.pm didn't add -lpgport. It looks out for the pattern PG_LIBS_INTERNAL = $(libpq_pgport), so that's an easy way to fix that -- is there a better way? I couldn't figure out how to tell it that we need libpqport but not libpq. Here's a CI run of these patches on top of REL_16_STABLE, showing the new Mkvcbuild.pm task passing: https://cirrus-ci.com/build/5900754273173504
0001-ci-Test-legacy-Windows-build-in-REL_16_STABLE.patch
Description: Binary data
0002-Fix-Mkvcbuild.pm-builds-of-test_cloexec.c.patch
Description: Binary data
