Re: Meson far from ready on Windows

Hi Tristan,

On Fri, 21 Jun 2024 at 18:16, Tristan Partin <tristan(at)partin(dot)io> wrote:

>
> Hey Dave,
>
> I'm a maintainer for Meson, and am happy to help you in any way that
> I reasonably can.
>

Thank you!

>
> Let's start with the state of Windows support in Meson. If I were to
> rank Meson support for platforms, I would do something like this:
>
> - Linux
> - BSDs
> - Solaris/IllumOS
> - ...
> - Apple
> - Windows
>
> As you can see Windows is the bottom of the totem pole. We don't have
> Windows people coming along to contribute very often for whatever
> reason. Thus admittedly, Windows support can be very lackluster at
> times.
>
> Meson is not a project which sees a lot of funding. (Do any build
> tools?) The projects that support Meson in any way are Mesa and
> GStreamer, which don't have a lot of incentive to do anything with
> Windows, generally.
>
> I'm not even sure any of the regular contributors to Meson have
> Windows development machines. I surely don't have access to a Windows
> machine.
>

To be very clear, my comments - in particular the subject line of this
thread - are not referring to Meson itself, rather our use of it on
Windows. I've been quite impressed with Meson in general, and am coming to
like it a lot.

>
> All that being said, I would like to help you solve your Windows
> dependencies issue, or at least mitigate them. I think it is probably
> best to just look at one dependency at a time. Here is how lz4 is picked
> up in the Postgres Meson build:
>
> > lz4opt = get_option('lz4')
> > if not lz4opt.disabled()
> > lz4 = dependency('liblz4', required: lz4opt)
> >
> > if lz4.found()
> > cdata.set('USE_LZ4', 1)
> > cdata.set('HAVE_LIBLZ4', 1)
> > endif
> >
> > else
> > lz4 = not_found_dep
> > endif
>
> As you are well aware, dependency() looks largely at pkgconfig and cmake
> to find the dependencies. In your case, that is obviously not working.
>
> I think there are two ways to solve your problem. A first solution would
> look like this:
>
> > lz4opt = get_option('lz4')
> > if not lz4opt.disabled()
> > lz4 = dependency('liblz4', required: false)
> > if not lz4.found()
> > lz4 = cc.find_library('lz4', required: lz4opt, dirs: extra_lib_dirs)
> > endif
> >
> > if lz4.found()
> > cdata.set('USE_LZ4', 1)
> > cdata.set('HAVE_LIBLZ4', 1)
> > end
> > else
> > lz4 = not_found_dep
> > endif
>

Yes, that's the pattern I think we should generally be using:

- It supports the design goals, allowing for configurations we don't know
about to be communicated through pkgconfig or cmake files.
- It provides a fallback method to detect the dependencies as we do in the
old MSVC build system, which should work with most dependencies built with
their "standard" configuration on Windows.

To address Andres' concerns around mis-detection of dependencies, or other
oddities such as required compiler flags not being included, I would
suggest that a) that's happened very rarely, if ever, in the past, and b)
we can always spit out an obvious warning if we've not been able to use
cmake or pkgconfig for any particular dependencies.

>
> Another solution that could work alongside the previous suggestion is to
> use Meson subprojects[0] for managing Postgres dependencies. I don't
> know if we would want this in the Postgres repo or a patch that
> downstream packagers would need to apply, but essentially, add the wrap
> file:
>
> > [wrap-file]
> > directory = lz4-1.9.4
> > source_url = https://github.com/lz4/lz4/archive/v1.9.4.tar.gz
> > source_filename = lz4-1.9.4.tgz
> > source_hash =
> 0b0e3aa07c8c063ddf40b082bdf7e37a1562bda40a0ff5272957f3e987e0e54b
> > patch_filename = lz4_1.9.4-2_patch.zip
> > patch_url = https://wrapdb.mesonbuild.com/v2/lz4_1.9.4-2/get_patch
> > patch_hash =
> 4f33456cce986167d23faf5d28a128e773746c10789950475d2155a7914630fb
> > wrapdb_version = 1.9.4-2
> >
> > [provide]
> > liblz4 = liblz4_dep
>
> into subprojects/lz4.wrap, and Meson should be able to automagically
> pick up the dependency. Do this for all the projects that Postgres
> depends on, and you'll have an entire build managed by Meson. Note that
> Meson subprojects don't have to use Meson themselves. They can also use
> CMake[1] or Autotools[2], but your results may vary.
>

That's certainly interesting functionality. I'm not sure we'd want to try
to use it here, simply because building all of PostgreSQL's dependencies on
Windows requires multiple different toolchains and environments and is not
trivial to setup. That's largely why I started working on
https://github.com/dpage/winpgbuild.

Thanks!

>
> Happy to hear your thoughts. I think if our goal is to enable more
> people to work on Postgres, we should probably add subproject wraps to
> the source tree, but we also need to be forgiving like in the Meson DSL
> snippet above.
>
> Let me know your thoughts!
>
> [0]: https://mesonbuild.com/Wrap-dependency-system-manual.html
> [1]:
> https://github.com/hse-project/hse/blob/6d5207f88044a3bd9b3539260074395317e276d5/meson.build#L239-L275
> [2]:
> https://github.com/hse-project/hse/blob/6d5207f88044a3bd9b3539260074395317e276d5/subprojects/packagefiles/libbsd/meson.build
>
> --
> Tristan Partin
> https://tristan.partin.io
>

--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
EDB: https://www.enterprisedb.com