On Fri Jun 21, 2024 at 10:46 AM CDT, Dave Page wrote:
On Fri, 21 Jun 2024 at 16:15, Robert Haas <robertmh...@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
