On 2023-05-03 We 14:26, Andres Freund wrote:
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
On 2023-04-27 Th 18:18, Andres Freund wrote:
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm support for meson:
Here's a simple illustration of the problem. If I do the identical test with
a non-meson build there is no problem:
This happens 100% reproducible?
For a sufficiently modern installation of msys2 (20230318 version) this is
reproducible on autoconf builds as well.
Oh. Seems like something we need to dig into independent of meson then :(
The main thing that's now an issue on Windows is support for various options
like libxml2. I installed the libxml2 distro from the package manager scoop,
generated .lib files for the libxml2 and libxslt DLLs, and was able to build
with autoconf on msys2, and with our MSVC support, but not with meson in
either case. It looks like we need to expand the logic in meson.build for a
number of these, just as we have done for perl, python, openssl, ldap etc.
I seriously doubt that trying to support every possible packaging thing on
windows is a good idea. What's the point of building against libraries from a
packaging solution that doesn't even come with .lib files? Windows already is
a massive pain to support for postgres, making it even more complicated / less
predictable is a really bad idea.
IMO, for windows, the path we should go down is to provide one documented way
to build the dependencies (e.g. using vcpkg or conan, perhaps also supporting
msys distributed libs), and define using something else to be unsupported (in
the "we don't help you", not in the "we explicitly try to break things"
sense). And it should be something that understands needing to build debug
and non-debug libraries.
I'm not familiar with conan. I have struggled considerably with vcpkg in the past.
I don't think there is any one perfect answer.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com