Re: Meson far from ready on Windows
Dave Page <dpage@pgadmin.org>
From: Dave Page <dpage@pgadmin.org>
To: Andres Freund <andres@anarazel.de>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-06-25T12:33:25Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
meson: Add dependency lookups via names used by cmake
- 5ec2c529f553 18.0 landed
- 13c58ca51883 16.4 landed
- 9ac6995d6b1f 17.0 landed
-
meson: Add support for detecting gss without pkg-config
- 7ed2ce0b257f 18.0 landed
- 2b4593379b81 16.4 landed
- a850701c7ddf 17.0 landed
-
meson: Add support for detecting ossp-uuid without pkg-config
- 2416fdb3ee30 18.0 landed
- 793a5bebebbe 16.4 landed
- 1213875b3a99 17.0 landed
Hi On Tue, 25 Jun 2024 at 12:39, Andres Freund <andres@anarazel.de> wrote: > Hi, > > On 2024-06-25 11:54:56 +0100, Dave Page wrote: > > https://github.com/dpage/winpgbuild proves that the hacks above are not > > required *if* you build the dependencies in the recommended way for use > > with MSVC++ (where documented), otherwise just native Windows. > > Partially it just means that some of the hacks are now located in the > "build > dependencies" script. E.g. you're renaming libintl.dll.a, libiconv.dll.a, > libuuid.a to something that's expected by the buildmethod. And the scripts > change the directory structure for several other dependencies (e.g. zstd, > krb). > > > > If you, for example, build a dependency using Mingw/Msys, then you may > get > > different filenames than if you build the same thing using its VC++ > > solution or makefile. That's where most, if not all, of these issues come > > from. > > Yes, that's precisely my point. The set of correct names / flags depends on > things outside of postgres control. Hence they should be handled outside of > postgres, not as part of postgres. Particularly because several of the > dependencies can be built in multiple ways, resulting in multiple library > names. And it doesn't even just differ by compiler, there's ways to get > different library names for some of the deps even with the same compiler! > Replying to this and your previous email. I think we're in violent agreement here as to how things *should* be in an ideal world. The issue for me is that this isn't an ideal world and the current solution potentially makes it much harder to get a working PostgreSQL build on Windows - not only that, but everyone doing those builds potentially has to figure out how to get things to work for themselves because we're pushing the knowledge outside of our build system. I've been building Postgres on Windows for years (and like to think I'm reasonably competent), and despite reading the docs I still ended up starting multiple threads on the hackers list to try to understand how to get v17 to build. Would we accept the current Meson setup on Linux if people had to hand-craft .pc files, or install dependencies using multiple third-party package managers to get it to work? As I previously noted, I think we should default to pkgconfig/cmake detection, but then fall back to what we did previously (with suitably obnoxious warnings). Then at least a build environment that worked in the past should work in the future. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com