Re: Meson far from ready on Windows - Mailing list pgsql-hackers

Hi,


On 2024-06-18 15:54:27 +0100, Dave Page wrote:
> On Tue, 18 Jun 2024 at 15:38, Andres Freund <andres@anarazel.de> wrote:
> > Do you have logs for those failures?
> >
>
> Sure - https://developer.pgadmin.org/~dpage/build-logs.zip. Those are all
> without any modifications to %LIB% or %INCLUDE%.

Thanks.


> > I think it's important to note that Meson largely seems to want to use
> > > pkgconfig and cmake to find dependencies. pkgconfig isn't really a thing
> > on
> > > Windows (it is available, but isn't commonly used), and even cmake would
> > > typically rely on finding things in either known installation directories
> > > or through lib/include vars.
> >
> > I am not really following what you mean with the cmake bit here?
> >
> > You can configure additional places to search for cmake files with
> > meson setup --cmake-prefix-path=...
> >
>
> None of the dependencies include cmake files for distribution on Windows,
> so there are no additional files to tell meson to search for. The same
> applies to pkgconfig files, which is why the EDB team had to manually craft
> them.

Many of them do include at least cmake files on windows if you build them
though?


Btw, I've been working with Bilal to add a few of the dependencies to the CI
images so we can test those automatically. Using vcpkg. We got that nearly
working, but he's on vacation this week...  That does ensure both cmake and
.pc files are generated, fwiw.

Currently builds gettext, icu, libxml2, libxslt, lz4, openssl, pkgconf,
python3, tcl, zlib, zstd.



I'm *NOT* sure that vcpkg is the way to go, fwiw. It does seem advantageous to
use one of the toolkits thats commonly built for building dependencies on
windows, which seems to mean vcpkg or conan.


> And that's why we really need to be able to locate headers and libraries
> easily by passing paths to meson, as we can't rely on pkgconfig, cmake, or
> things being in some standard directory on Windows.

Except that that often causes hard to diagnose breakages, because that doesn't
allow including the necessary compiler/linker flags [2].  It's a bad model, we shouldn't
perpetuate it.  If we want to forever make windows a complicated annoying
stepchild, that's the way to go.

FWIW, at least libzstd, libxml [3], lz4, zlib can generate cmake dependency
files on windows in their upstream code.

I'm *not* against adding "hardcoded" dependency lookup stuff for libraries
where other approaches aren't feasible, I just don't think it's a good idea to
add fragile stuff that will barely be tested, when not necessary.

Greetings,

Andres Freund


[1] Here's a build of PG with the dependencies installed, builds
    https://cirrus-ci.com/task/4953968097361920

[2] E.g.
    https://github.com/postgres/postgres/blob/REL_16_STABLE/src/tools/msvc/Mkvcbuild.pm#L600
    https://github.com/postgres/postgres/blob/REL_16_STABLE/src/tools/msvc/Solution.pm#L1039

[3] Actually, at least your libxml build actually *did* include both .pc and
    cmake files. So just pointing to the relevant path would do the trick.