On Thu, Dec 04, 2025 at 05:11:15PM -0300, Euler Taveira wrote:
> Here it is v2. It enforces the lz4 dependency. It works the same as other
> dependencies (readline, icu, zlib); error if the dependency could not be found.
> Regarding meson, I'm confused. If any of the referred dependencies (icu,
> readline, zlib) is not found, there is no hard error. Instead, the feature is
> disabled. I searched for a discussion about this decision but couldn't find.
> For this patch, I decided to use the same pattern (no error) but I added a
> warning message (similar to zlib).
Another thing to be careful of is that this would immediately break
the CI task CompilerWarnings for mingw:
[02:03:19.626] checking whether to build with LZ4 support... yes
[02:03:19.626] checking for liblz4... no
[02:03:19.694] configure: error: Package requirements (liblz4) were
not met:
So this had better be adjusted in one go, in the shape of a tweak in
mingw_cross_warning_script with the addition of a --without-lz4, same
way as for ICU.
> Should it report an error (like autoconf) instead of silently disable the
> feature that is a requirement? If yes, then we should add error messages for
> these 3 dependencies.
Hmm. It seems to me that we should just set not_found_dep if lz4
cannot be found, leaving meson_options.txt as it is currently, no?
One could always force meson's hand with -Dlz4=disabled. As a whole,
I'd value more consistency with how icu is handled if we want to force
LZ4 across the board in the backend. The case with zlib is different
in the backend: we only use it on a wanted-basis for compression
specifications in server-side compressed base backups, so it seems to
me that there's a case for being a tad more aggressive with LZ4 as it
relates to TOAST compression, forcing an error rather than ignoring it
silently if it cannot be found.
--
Michael
