Explicitly enable meson features in CI

On 2 Jul 2025, at 09:22, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Right now, many features are set to auto in Meson builds in CI. This
means Meson tries to detect these features automatically but does not
report an error if it fails to find them. Jacob stated [1] that this
behavior can lead to issues, such as missing problems in the build
system. Additionally, since CI images are updated automatically, an
update could cause a feature to go missing without any warning.
Therefore, Jacob suggested explicitly enabling these features in the
Meson build configuration. The attached patch implements this change.

Big +1 on this, thanks for tackling it.

--
Daniel Gustafsson

On 02.07.25 09:22, Nazir Bilal Yavuz wrote:

One thing I’m unsure about the patch is that all these features are
stored in the MESON_FEATURES environment variable in each task. I
wonder if it might be clearer to rename these variables to
${TASK_NAME}_MESON_FEATURES to avoid confusion.

I would hope we could do this without so much repetition. Why not a
global variable and then have each task override as needed?

(It would also be nice to extra the corresponding configure arguments
into a similar variable, so we can easily keep this aligned.)

Here is a sketch of what I mean:

env:
...
PG_TEST_EXTRA: ...
MESON_COMMON_ARGS: -Dauto_features=disabled -Ddocs=enabled ...
CONFIGURE_COMMON_ARGS: --with-gssapi --with-icu --with-ldap ...

...

configure_script: |
su postgres <<-EOF
meson setup \
${MESON_COMMON_ARGS} -Dpltcl=disabled \
--buildtype=debugoptimized \
--pkg-config-path ${PKGCONFIG_PATH} \
-Dcassert=true -Dinjection_points=true \
-Dssl=openssl ${UUID} ${TCL} \
-DPG_TEST_EXTRA="$PG_TEST_EXTRA" \
build
EOF

(There are additional opportunities to refactor this, such as the
-DPG_TEST_EXTRA option that is repeated everywhere.)

Hi,

Thank you for looking into this!

On Wed, 2 Jul 2025 at 14:33, Peter Eisentraut <peter@eisentraut.org> wrote:

On 02.07.25 09:22, Nazir Bilal Yavuz wrote:

One thing I’m unsure about the patch is that all these features are
stored in the MESON_FEATURES environment variable in each task. I
wonder if it might be clearer to rename these variables to
${TASK_NAME}_MESON_FEATURES to avoid confusion.

I would hope we could do this without so much repetition. Why not a
global variable and then have each task override as needed?

(It would also be nice to extra the corresponding configure arguments
into a similar variable, so we can easily keep this aligned.)

Common configure arguments are '-Dcassert=true
-Dinjection_points=true', I addressed that in the 0003.

Here is a sketch of what I mean:

env:
...
PG_TEST_EXTRA: ...
MESON_COMMON_ARGS: -Dauto_features=disabled -Ddocs=enabled ...
CONFIGURE_COMMON_ARGS: --with-gssapi --with-icu --with-ldap ...

I agree that this repetition does not look good but my idea was to be
able to see which features are enabled at one glance. I tried to apply
grouping in v2:

1) args that are shared between all meson tasks except SanityCheck
are: auto_features, ldap, ssl=openssl, tap_tests, plperl, plpython
2) args that are shared between all meson tasks except SanityCheck and
Windows VS task are: docs, icu, libxml, libxslt, lz4, pltcl, readline,
zlib, zstd

I stored #1 in the MESON_COMMON_FEATURES variable and #2 in the
MESON_NON_VS_FEATURES variable. Then merged #1 and #2 in the
MESON_COMMON_NON_VS_FEATURES variable. So it is like that:

- All meson tasks excluding the Windows VS and SanityCheck tasks use
MESON_COMMON_NON_VS_FEATURES and overrides it.
- Windows VS task uses MESON_COMMON_FEATURES.

...

configure_script: |
su postgres <<-EOF
meson setup \
${MESON_COMMON_ARGS} -Dpltcl=disabled \
--buildtype=debugoptimized \
--pkg-config-path ${PKGCONFIG_PATH} \
-Dcassert=true -Dinjection_points=true \
-Dssl=openssl ${UUID} ${TCL} \
-DPG_TEST_EXTRA="$PG_TEST_EXTRA" \
build
EOF

(There are additional opportunities to refactor this, such as the
-DPG_TEST_EXTRA option that is repeated everywhere.)

-DPG_TEST_EXTRA option is used only in the NetBSD and OpenBSD tasks
but it is unnecessary. They can use the top level PG_TEST_EXTRA
environment variable. This is fixed in 0001.

To sum up:

0001 is for removing unnecessary PG_TEST_EXTRA from the NetBSD and
OpenBSD tasks.
0002 is the actual patch but this time I tried to address that
repetition problem by storing common meson features in variables.
0003 is storing common configure arguments ('-Dcassert=true
-Dinjection_points=true') in one variable.

--
Regards,
Nazir Bilal Yavuz
Microsoft

On 3 Jul 2025, at 09:27, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
On Wed, 2 Jul 2025 at 14:33, Peter Eisentraut <peter@eisentraut.org> wrote:

Here is a sketch of what I mean:

env:
...
PG_TEST_EXTRA: ...
MESON_COMMON_ARGS: -Dauto_features=disabled -Ddocs=enabled ...
CONFIGURE_COMMON_ARGS: --with-gssapi --with-icu --with-ldap ...

I agree that this repetition does not look good but my idea was to be
able to see which features are enabled at one glance. I tried to apply
grouping in v2:

FWIW, I didn't mind the repetition in v1 but I won't argue against the current
approach either.

+  # Like 'MESON_COMMON_FEATURES' but not shared with 'Windows - VS' task too
+  MESON_NON_VS_FEATURES: >-

I'm not a fan of this name, it feel a bit unintuitive to describe what it isn't
instead of what it is. How about MESON_LINUX_UNIX_FEATURES or something along
those lines?

   # disable -Dnls as the number of files it creates cause a noticable slowdown
   configure_script: |
-    %BASH% -c "meson setup -Ddebug=true -Doptimization=g -Dcassert=true -Dinjection_points=true -Db_pch=true -Dnls=disabled -DTAR=%TAR
% build"
+    %BASH% -c "meson setup %MESON_COMMON_PG_CONFIG_ARGS%  -Ddebug=true -Doptimization=g -Db_pch=true %MESON_COMMON_NON_VS_FEATURES% -D
TAR=%TAR% build"

The MinGW build no longer disables nls, or am I missing something?

--
Daniel Gustafsson

Hi,

Thank you for looking into this!

On Thu, 3 Jul 2025 at 16:21, Daniel Gustafsson <daniel@yesql.se> wrote:

On 3 Jul 2025, at 09:27, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
On Wed, 2 Jul 2025 at 14:33, Peter Eisentraut <peter@eisentraut.org> wrote:

Here is a sketch of what I mean:

env:
...
PG_TEST_EXTRA: ...
MESON_COMMON_ARGS: -Dauto_features=disabled -Ddocs=enabled ...
CONFIGURE_COMMON_ARGS: --with-gssapi --with-icu --with-ldap ...

I agree that this repetition does not look good but my idea was to be
able to see which features are enabled at one glance. I tried to apply
grouping in v2:

FWIW, I didn't mind the repetition in v1 but I won't argue against the current
approach either.

I feel the same.

+  # Like 'MESON_COMMON_FEATURES' but not shared with 'Windows - VS' task too
+  MESON_NON_VS_FEATURES: >-

I'm not a fan of this name, it feel a bit unintuitive to describe what it isn't
instead of what it is. How about MESON_LINUX_UNIX_FEATURES or something along
those lines?

I agree that MESON_NON_VS_FEATURES is not intuitive but can MinGW be
considered as LINUX or UNIX?

# disable -Dnls as the number of files it creates cause a noticable slowdown
configure_script: |
-    %BASH% -c "meson setup -Ddebug=true -Doptimization=g -Dcassert=true -Dinjection_points=true -Db_pch=true -Dnls=disabled -DTAR=%TAR
% build"
+    %BASH% -c "meson setup %MESON_COMMON_PG_CONFIG_ARGS%  -Ddebug=true -Doptimization=g -Db_pch=true %MESON_COMMON_NON_VS_FEATURES% -D
TAR=%TAR% build"

The MinGW build no longer disables nls, or am I missing something?

Auto features are already disabled. So, there is no need to disable
nls manually. By saying that, it would be better to remove this
comment now.

--
Regards,
Nazir Bilal Yavuz
Microsoft

On 3 Jul 2025, at 15:50, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
On Thu, 3 Jul 2025 at 16:21, Daniel Gustafsson <daniel@yesql.se> wrote:

+  # Like 'MESON_COMMON_FEATURES' but not shared with 'Windows - VS' task too
+  MESON_NON_VS_FEATURES: >-

I'm not a fan of this name, it feel a bit unintuitive to describe what it isn't
instead of what it is. How about MESON_LINUX_UNIX_FEATURES or something along
those lines?

I agree that MESON_NON_VS_FEATURES is not intuitive but can MinGW be
considered as LINUX or UNIX?

That is an excellent question, according to our fine documentation it is a
"Unix-like build environment".

An alternative approach would be to instead of having opt-in's for non-Windows
have opt-outs for Windows, ie a MESON_WINDOWS_EXCLUDES which does =disabled on
the specific features we dont want on Windows?

The MinGW build no longer disables nls, or am I missing something?

Auto features are already disabled. So, there is no need to disable
nls manually. By saying that, it would be better to remove this
comment now.

Aha, that explains it. Maybe reword the comment to retain the knowledge for
the future without making it sound like something is missing from the command.
How about something like:

-  # disable -Dnls as the number of files it creates cause a noticable slowdown
+  # -Dnls need to be disabled as the number of files it creates cause a
+  # noticable slowdown

--
Daniel Gustafsson

Hi,

On Thu, 3 Jul 2025 at 17:07, Daniel Gustafsson <daniel@yesql.se> wrote:

On 3 Jul 2025, at 15:50, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
On Thu, 3 Jul 2025 at 16:21, Daniel Gustafsson <daniel@yesql.se> wrote:

+  # Like 'MESON_COMMON_FEATURES' but not shared with 'Windows - VS' task too
+  MESON_NON_VS_FEATURES: >-

I'm not a fan of this name, it feel a bit unintuitive to describe what it isn't
instead of what it is. How about MESON_LINUX_UNIX_FEATURES or something along
those lines?

I agree that MESON_NON_VS_FEATURES is not intuitive but can MinGW be
considered as LINUX or UNIX?

That is an excellent question, according to our fine documentation it is a
"Unix-like build environment".

An alternative approach would be to instead of having opt-in's for non-Windows
have opt-outs for Windows, ie a MESON_WINDOWS_EXCLUDES which does =disabled on
the specific features we dont want on Windows?

I think this would make things complicated. Instead, we can set
Windows VS tasks' features in its task, then we can have a one common
feature variable at the top level and have a comment about this
variable not being used in the Windows VS task. Basically the same
with your approach but instead of using a common feature variable and
disabling features from it, we enable them again in the Windows VS
task. I used this approach in the v3-0002.

The MinGW build no longer disables nls, or am I missing something?

Auto features are already disabled. So, there is no need to disable
nls manually. By saying that, it would be better to remove this
comment now.

Aha, that explains it. Maybe reword the comment to retain the knowledge for
the future without making it sound like something is missing from the command.
How about something like:

-  # disable -Dnls as the number of files it creates cause a noticable slowdown
+  # -Dnls need to be disabled as the number of files it creates cause a
+  # noticable slowdown

Yes, I think this is better. Done.

--
Regards,
Nazir Bilal Yavuz
Microsoft

On 4 Jul 2025, at 09:33, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
On Thu, 3 Jul 2025 at 17:07, Daniel Gustafsson <daniel@yesql.se> wrote:

An alternative approach would be to instead of having opt-in's for non-Windows
have opt-outs for Windows, ie a MESON_WINDOWS_EXCLUDES which does =disabled on
the specific features we dont want on Windows?

I think this would make things complicated.

I think you're right.

Instead, we can set
Windows VS tasks' features in its task, then we can have a one common
feature variable at the top level and have a comment about this
variable not being used in the Windows VS task. Basically the same
with your approach but instead of using a common feature variable and
disabling features from it, we enable them again in the Windows VS
task. I used this approach in the v3-0002.

The proposal in v3 strikes a good balance between avoiding repetition and being
readable.

--
Daniel Gustafsson

Hi,

On Wed, 2 Jul 2025 at 10:22, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Also, libcurl is disabled in the OpenBSD CI task until the fix in this
thread [1] is committed.

This fix is committed in 7376e60854 so libcurl is enabled for OpenBSD in v4.

--
Regards,
Nazir Bilal Yavuz
Microsoft

Hi,

On Tue, 8 Jul 2025 at 12:10, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Hi,

On Wed, 2 Jul 2025 at 10:22, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Also, libcurl is disabled in the OpenBSD CI task until the fix in this
thread [1] is committed.

This fix is committed in 7376e60854 so libcurl is enabled for OpenBSD in v4.

Andres off-list mentioned that if we explicitly enable features for
*all* of the tasks, then none of the tasks will be testing the auto
feature option and I agree with Andres. My suggestion is setting
features to auto for Debian - Meson task. I decided on this because I
think it is the most checked CI task so it would be easier to catch if
one of the features is disabled without anyone noticing.

--
Regards,
Nazir Bilal Yavuz
Microsoft

On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Andres off-list mentioned that if we explicitly enable features for
*all* of the tasks, then none of the tasks will be testing the auto
feature option and I agree with Andres. My suggestion is setting
features to auto for Debian - Meson task. I decided on this because I
think it is the most checked CI task

Hehe, that's certainly true for me...

so it would be easier to catch if
one of the features is disabled without anyone noticing.

Seems reasonable. If we do this, can we rename the job with a "- Meson
Auto" suffix or something, to try to call the difference out
explicitly?

--Jacob

On 10 Jul 2025, at 19:12, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

so it would be easier to catch if
one of the features is disabled without anyone noticing.

Seems reasonable.

Agreed.

If we do this, can we rename the job with a "- Meson
Auto" suffix or something, to try to call the difference out
explicitly?

+1

--
Daniel Gustafsson

Hi,

On Thu, 10 Jul 2025 at 20:12, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:

On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Andres off-list mentioned that if we explicitly enable features for
*all* of the tasks, then none of the tasks will be testing the auto
feature option and I agree with Andres. My suggestion is setting
features to auto for Debian - Meson task. I decided on this because I
think it is the most checked CI task

Hehe, that's certainly true for me...

so it would be easier to catch if
one of the features is disabled without anyone noticing.

Seems reasonable. If we do this, can we rename the job with a "- Meson
Auto" suffix or something, to try to call the difference out
explicitly?

I think renaming it would be better but then we have two Linux tasks:

- Linux - Debian Bookworm - Autoconf
- Linux - Debian Bookworm - Meson Auto

For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We
can rename it as a 'Meson Auto Feature Detection' but that is a bit
longer. Do you have any ideas? If you think 'Meson Auto' is good
enough, we can continue with it, too.

--
Regards,
Nazir Bilal Yavuz
Microsoft

Hi,

On Fri, 11 Jul 2025 at 14:00, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Hi,

On Thu, 10 Jul 2025 at 20:12, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:

On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Andres off-list mentioned that if we explicitly enable features for
*all* of the tasks, then none of the tasks will be testing the auto
feature option and I agree with Andres. My suggestion is setting
features to auto for Debian - Meson task. I decided on this because I
think it is the most checked CI task

Hehe, that's certainly true for me...

so it would be easier to catch if
one of the features is disabled without anyone noticing.

Seems reasonable. If we do this, can we rename the job with a "- Meson
Auto" suffix or something, to try to call the difference out
explicitly?

I think renaming it would be better but then we have two Linux tasks:

- Linux - Debian Bookworm - Autoconf
- Linux - Debian Bookworm - Meson Auto

For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We
can rename it as a 'Meson Auto Feature Detection' but that is a bit
longer. Do you have any ideas? If you think 'Meson Auto' is good
enough, we can continue with it, too.

I renamed 'Meson Auto' as 'Meson Auto Feature Detection' in v5.

--
Regards,
Nazir Bilal Yavuz
Microsoft

On Wed, Jul 16, 2025 at 4:12 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We
can rename it as a 'Meson Auto Feature Detection' but that is a bit
longer. Do you have any ideas? If you think 'Meson Auto' is good
enough, we can continue with it, too.

I renamed 'Meson Auto' as 'Meson Auto Feature Detection' in v5.

Sorry for the delay -- while that feels a little wordy to me, it's
also trivially changed. Not worth bikeshedding over unless someone
else complains, IMO. :D

Is there anything else in particular you'd like review on? (I've
marked this patchset RfC.)

Thanks,
--Jacob

Hi,

On 2025-07-16 14:12:22 +0300, Nazir Bilal Yavuz wrote:

On Fri, 11 Jul 2025 at 14:00, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

On Thu, 10 Jul 2025 at 20:12, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:

On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Andres off-list mentioned that if we explicitly enable features for
*all* of the tasks, then none of the tasks will be testing the auto
feature option and I agree with Andres. My suggestion is setting
features to auto for Debian - Meson task. I decided on this because I
think it is the most checked CI task

Hehe, that's certainly true for me...

so it would be easier to catch if
one of the features is disabled without anyone noticing.

Seems reasonable. If we do this, can we rename the job with a "- Meson
Auto" suffix or something, to try to call the difference out
explicitly?

I think renaming it would be better but then we have two Linux tasks:

- Linux - Debian Bookworm - Autoconf
- Linux - Debian Bookworm - Meson Auto

For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We
can rename it as a 'Meson Auto Feature Detection' but that is a bit
longer. Do you have any ideas? If you think 'Meson Auto' is good
enough, we can continue with it, too.

I renamed 'Meson Auto' as 'Meson Auto Feature Detection' in v5.

FWIW, I don't think it's a good idea to the Auto bit to the name. We have
several special things about various tests, if we add all of them to the task
name, we'll have very long task names. This one would already be

Linux - Debian Bookworm - Meson Auto Features Detection - 32 and 64 Bit build & tests - Alignment, Undefined Behaviour Sanitizer - IO method=io_uring

And the task names would change a lot more, which is also a pain for things
like the commitfest / cfbot web apps.

But it *should* be added to the "SPECIAL:" comment.

Greetings,

Andres Freund

Hi,

On Wed, 16 Jul 2025 at 19:02, Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2025-07-16 14:12:22 +0300, Nazir Bilal Yavuz wrote:

On Fri, 11 Jul 2025 at 14:00, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

On Thu, 10 Jul 2025 at 20:12, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:

On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

Andres off-list mentioned that if we explicitly enable features for
*all* of the tasks, then none of the tasks will be testing the auto
feature option and I agree with Andres. My suggestion is setting
features to auto for Debian - Meson task. I decided on this because I
think it is the most checked CI task

Hehe, that's certainly true for me...

so it would be easier to catch if
one of the features is disabled without anyone noticing.

Seems reasonable. If we do this, can we rename the job with a "- Meson
Auto" suffix or something, to try to call the difference out
explicitly?

I think renaming it would be better but then we have two Linux tasks:

- Linux - Debian Bookworm - Autoconf
- Linux - Debian Bookworm - Meson Auto

For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We
can rename it as a 'Meson Auto Feature Detection' but that is a bit
longer. Do you have any ideas? If you think 'Meson Auto' is good
enough, we can continue with it, too.

I renamed 'Meson Auto' as 'Meson Auto Feature Detection' in v5.

FWIW, I don't think it's a good idea to the Auto bit to the name. We have
several special things about various tests, if we add all of them to the task
name, we'll have very long task names. This one would already be

Linux - Debian Bookworm - Meson Auto Features Detection - 32 and 64 Bit build & tests - Alignment, Undefined Behaviour Sanitizer - IO method=io_uring

And the task names would change a lot more, which is also a pain for things
like the commitfest / cfbot web apps.

I don't have a strong opinion on this. I think the naming change
clarifies things but as you said then we may/should add other specific
settings to the task name. So, I reverted the naming change.

But it *should* be added to the "SPECIAL:" comment.

Done.

v6 is attached.

--
Regards,
Nazir Bilal Yavuz
Microsoft

Hi,

On Wed, 16 Jul 2025 at 18:24, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:

On Wed, Jul 16, 2025 at 4:12 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We
can rename it as a 'Meson Auto Feature Detection' but that is a bit
longer. Do you have any ideas? If you think 'Meson Auto' is good
enough, we can continue with it, too.

I renamed 'Meson Auto' as 'Meson Auto Feature Detection' in v5.

Sorry for the delay -- while that feels a little wordy to me, it's
also trivially changed. Not worth bikeshedding over unless someone
else complains, IMO. :D

I reverted the naming change in v6 based on Andres' comments [1]/messages/by-id/zltxefhw7bej3o4oxvkfuoa2glbnip3jacp7rvacbrv5oepql3@gs3lbwg6unmv.

Is there anything else in particular you'd like review on? (I've
marked this patchset RfC.)

Not at the moment, thank you so much!

[1]: /messages/by-id/zltxefhw7bej3o4oxvkfuoa2glbnip3jacp7rvacbrv5oepql3@gs3lbwg6unmv

--
Regards,
Nazir Bilal Yavuz
Microsoft

On 17 Jul 2025, at 10:33, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
On Wed, 16 Jul 2025 at 18:24, Jacob Champion <jacob.champion@enterprisedb.com> wrote:

Is there anything else in particular you'd like review on? (I've
marked this patchset RfC.)

Reading over the v6 version posted upthread, I agree with the patch being
ready. Are you taking care of it Jacob?

-  # disable -Dnls as the number of files it creates cause a noticable slowdown
+  # -Dnls need to be disabled as the number of files it creates cause a noticable slowdown

I think this should be s/noticable/noticeable/ (which is a nitpick a commmitter
can deal with, no need for a new version IMO).

--
Daniel Gustafsson