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

On Fri Jun 21, 2024 at 10:46 AM CDT, Dave Page wrote:
> On Fri, 21 Jun 2024 at 16:15, Robert Haas <robertmhaas@gmail.com> wrote:
> > As a practical matter, I don't think MSVC is coming back. The
> > buildfarm was already changed over to use meson, and it would be
> > pretty disruptive to try to re-add buildfarm coverage for a
> > resurrected MSVC on the eve of beta2. I think we should focus on
> > improving whatever isn't quite right in meson -- plenty of other
> > people have also complained about various things there, me included --
> > rather than trying to undo over a year's worth of work by lots of
> > people to get things on Windows switched over to MSVC.
> >
>
> The buildfarm hasn't switched over - it had support added for Meson. If it
> had been switched, then the older back branches would have gone red.
>
> Anyway, that's immaterial - I know the old code isn't coming back now. My
> motivation for this thread is to get Meson to a usable state on Windows,
> that doesn't require hacking stuff around for the casual builder moving
> forwards - and at present, it requires *significantly* more hacking around
> than it has in many years.
>
> The design goals Andres spoke about would clearly be a technical
> improvement to PostgreSQL, however as we're finding, they rely on the
> upstream dependencies being built with pkgconfig or cmake files which
> either doesn't happen at present, or only happens if you happen to build in
> a certain way, or download from some source that has added them. I'm not
> sure how to fix that without re-introducing the old hacks in the build
> system, or extending my side project to add .pc files to all the
> dependencies it builds. I will almost certainly do that, as it'll give
> folks a single place where they can download everything they need, and
> provide a reference on how everything can be built if they want to do it
> themselves, but on the other hand, it's far from an ideal solution and I'd
> much prefer if I didn't need to do that at all.

Hey Dave,

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

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.

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

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.

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