Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain
| От | Thomas Munro |
|---|---|
| Тема | Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain |
| Дата | |
| Msg-id | CA+hUKG+-d0OyLMdMiZ+Ftj2hhZXT+0HOyHfrPBecE_vZzh9rRg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain
|
| Список | pgsql-hackers |
On Mon, Dec 22, 2025 at 11:48 AM Tom Lane <tgl@sss.pgh.pa.us> 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...
В списке pgsql-hackers по дате отправления: