Feedback-ID: idd01497b:Fastmail
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8; format=Flowed
Date: Fri, 21 Jun 2024 12:16:06 -0500
Message-Id: <D25V5ORSR9Y9.28Y5P45CO7Z4I@partin.io>
Cc: "Andres Freund" <andres@anarazel.de>, "Nazir Bilal Yavuz"
 <byavuz81@gmail.com>, "PostgreSQL Developers"
 <pgsql-hackers@lists.postgresql.org>
Subject: Re: Meson far from ready on Windows
To: "Dave Page" <dpage@pgadmin.org>, "Robert Haas" <robertmhaas@gmail.com>
From: "Tristan Partin" <tristan@partin.io>
References: <CA+OCxowQhMHFNRLTsXNuJpC96KRtSPHYKJuOS=b-Zrwmy-P4-g@mail.gmail.com> <20240618143850.nl67cwctsodmgfpi@awork3.anarazel.de> <CA+OCxoxwwA7u3mw9r7+miRzxdwzet9=Xq3JxVFpkd6TajP9eGA@mail.gmail.com> <20240618160845.gbqkiv4dbjghlp63@awork3.anarazel.de> <CA+OCxozsg3NOkTfK4KCb0gmxwnaNv4P=yuMZe_CgeXTM=ZGW7g@mail.gmail.com> <20240620205849.whd3434zoqqm2iy4@awork3.anarazel.de> <CA+OCxoxJ075+R63sgsHBExB+x3BV3o1xs9EBxGEuYmZQOkW=UQ@mail.gmail.com> <CA+TgmoahVnSsT-GoyPSYWNtEzi=0UYUyZAk-p6qiVUVibxbtNQ@mail.gmail.com> <CA+OCxoxXkTziDGAgU=hHMWTQ07YiohLXr_bFeCGX6-7s0SO3Xw@mail.gmail.com>
In-Reply-To: <CA+OCxoxXkTziDGAgU=hHMWTQ07YiohLXr_bFeCGX6-7s0SO3Xw@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/D25V5ORSR9Y9.28Y5P45CO7Z4I%40partin.io>
Precedence: bulk

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 i=
t
> 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 aroun=
d
> 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=20
I reasonably can.

Let's start with the state of Windows support in Meson. If I were to=20
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=20
Windows people coming along to contribute very often for whatever=20
reason. Thus admittedly, Windows support can be very lackluster at=20
times.

Meson is not a project which sees a lot of funding. (Do any build=20
tools?) The projects that support Meson in any way are Mesa and=20
GStreamer, which don't have a lot of incentive to do anything with=20
Windows, generally.

I'm not even sure any of the regular contributors to Meson have=20
Windows development machines. I surely don't have access to a Windows=20
machine.

All that being said, I would like to help you solve your Windows=20
dependencies issue, or at least mitigate them. I think it is probably=20
best to just look at one dependency at a time. Here is how lz4 is picked=20
up in the Postgres Meson build:

> lz4opt =3D get_option('lz4')
> if not lz4opt.disabled()
>   lz4 =3D dependency('liblz4', required: lz4opt)
>=20
>   if lz4.found()
>     cdata.set('USE_LZ4', 1)
>     cdata.set('HAVE_LIBLZ4', 1)
>   endif
>=20
> else
>   lz4 =3D not_found_dep
> endif

As you are well aware, dependency() looks largely at pkgconfig and cmake=20
to find the dependencies. In your case, that is obviously not working.=20

I think there are two ways to solve your problem. A first solution would=20
look like this:

> lz4opt =3D get_option('lz4')
> if not lz4opt.disabled()
>   lz4 =3D dependency('liblz4', required: false)
>   if not lz4.found()
>     lz4 =3D cc.find_library('lz4', required: lz4opt, dirs: extra_lib_dirs=
)
>   endif
>=20
>   if lz4.found()
>     cdata.set('USE_LZ4', 1)
>     cdata.set('HAVE_LIBLZ4', 1)
>   end
> else
>   lz4 =3D not_found_dep
> endif

Another solution that could work alongside the previous suggestion is to=20
use Meson subprojects[0] for managing Postgres dependencies. I don't=20
know if we would want this in the Postgres repo or a patch that=20
downstream packagers would need to apply, but essentially, add the wrap=20
file:

> [wrap-file]
> directory =3D lz4-1.9.4
> source_url =3D https://github.com/lz4/lz4/archive/v1.9.4.tar.gz
> source_filename =3D lz4-1.9.4.tgz
> source_hash =3D 0b0e3aa07c8c063ddf40b082bdf7e37a1562bda40a0ff5272957f3e98=
7e0e54b
> patch_filename =3D lz4_1.9.4-2_patch.zip
> patch_url =3D https://wrapdb.mesonbuild.com/v2/lz4_1.9.4-2/get_patch
> patch_hash =3D 4f33456cce986167d23faf5d28a128e773746c10789950475d2155a791=
4630fb
> wrapdb_version =3D 1.9.4-2
>=20
> [provide]
> liblz4 =3D liblz4_dep

into subprojects/lz4.wrap, and Meson should be able to automagically=20
pick up the dependency. Do this for all the projects that Postgres=20
depends on, and you'll have an entire build managed by Meson. Note that=20
Meson subprojects don't have to use Meson themselves. They can also use=20
CMake[1] or Autotools[2], but your results may vary.

Happy to hear your thoughts. I think if our goal is to enable more=20
people to work on Postgres, we should probably add subproject wraps to=20
the source tree, but we also need to be forgiving like in the Meson DSL=20
snippet above.

Let me know your thoughts!

[0]: https://mesonbuild.com/Wrap-dependency-system-manual.html
[1]: https://github.com/hse-project/hse/blob/6d5207f88044a3bd9b353926007439=
5317e276d5/meson.build#L239-L275
[2]: https://github.com/hse-project/hse/blob/6d5207f88044a3bd9b353926007439=
5317e276d5/subprojects/packagefiles/libbsd/meson.build

--=20
Tristan Partin
https://tristan.partin.io