Re: Meson far from ready on Windows - Mailing list pgsql-hackers
| From | Dave Page |
|---|---|
| Subject | Re: Meson far from ready on Windows |
| Date | |
| Msg-id | CA+OCxox7_Q37ObWyGFsn8mjAhJu5=x5a1ZaFdNsEN6EYYYXqBw@mail.gmail.com Whole thread Raw |
| In response to | Re: Meson far from ready on Windows ("Tristan Partin" <tristan@partin.io>) |
| Responses |
Re: Meson far from ready on Windows
|
| List | pgsql-hackers |
Hi Tristan,
On Fri, 21 Jun 2024 at 18:16, Tristan Partin <tristan@partin.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
pgsql-hackers by date: