[rpms/mariadb-connector-c] f44: [packaging bugfix] Add '-N' (read-only) flag to 'cmake -LAH' cache dump

[rpms/mariadb-connector-c] f44: [packaging bugfix] Add '-N' (read-only) flag to 'cmake -LAH' cache dump

[Michal Schorm]

            A new commit has been pushed.

            Repo   : rpms/mariadb-connector-c
            Branch : f44
            Commit : 3fc101ae079b9ec77bcbb338152476c128fa51c2
            Author : Michal Schorm <mschorm@redhat.com>
            Date   : 2026-06-24T20:21:38+02:00
            Stats  : +2/-1 in 1 file(s)
            URL    : https://src.fedoraproject.org/rpms/mariadb-connector-c/c/3fc101ae079b9ec77bcbb338152476c128fa51c2?branch=f44

            Log:
            [packaging bugfix] Add '-N' (read-only) flag to 'cmake -LAH' cache dump

I discovered that the second call of 'cmake -LAH' further changes the CMake cache.
That was definitely unintended. Applying '-N' to operate in 'cache read-only' mode.

That however breaks the build in the case we manually further manipulate the compilation
flags between the CMake calls, since now the flags won't propagate inside of the CMake
cache. This issue has two solutions:
  1) Move the code adjusting the build flags before the first CMake call
     so the changes are picked up during the first CMake call,
     however this requires calling the 'export' command.
  2) Use only the RPM macros for the build flags adjustments (which should be sufficient
     for most SPECfiles) since the RPM macros are all expanded before the build, in most
     cases the order does not matter.

I believe the correct way is to minimize manual operations and use the RPM macros wherever
possible. In this package the debug build flags already use '%{_pkg_extra_cflags}' macros,
so the '-N' addition is safe -- no manual flag exports exist between the '%cmake' and
'cmake -LAH' calls.

--

For the record, here is how the RPM macro approach works:

The build flags are set via the '%{set_build_flags}' macro.
This macro is automatically called numerous times -- at the beginning of the '%build'
phase, '%install' phase, '%check' phase. Also the '%cmake' macro calls it.

The macro '%{set_build_flags}' consists of:
 | CFLAGS="${CFLAGS:-%{build_cflags}}" ; export CFLAGS ; \
 | ...
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/d76f82/f/macros#_90

So it's not re-initialized if it's not empty.
That means it is possible to manipulate them via 'export' command and the adjusted value
will be used from that moment on.

The macro '%{build_cflags}' consists of:
 | %{__build_flags_lang_c} %{?_distro_extra_cflags}
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/d76f82/f/macros#_60

There the '%{_distro_extra_cflags}' macro is used.
This macro is intended for specifying extra build flags by the package maintainer,
so instead of the manual way like:
 | CFLAGS="$CFLAGS -O0 -g"
 | export CFLAGS
it suffices to use:
 | %global _distro_extra_cflags "-O0 -g"
and it will automatically propagate to every instance of the '%{set_build_flags}' macro,
not just the ones after the manual adjustments.

A great overview of the macros and how they are intended to be used can be found here:
  https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md

See b74fb13bdb57e7c3b3bfe3cd20ff8cfacfe1316a in the 'mariadb11.8' Fedora package
for a case where this actively broke the build.

Co-Authored-By: Claude AI <noreply@anthropic.com>

---
diff --git a/mariadb-connector-c.spec b/mariadb-connector-c.spec
index 316fabe..1f5f941 100644
--- a/mariadb-connector-c.spec
+++ b/mariadb-connector-c.spec
@@ -146,7 +146,8 @@ rm -r win win-iconv external/zlib
        -DWITH_UNIT_TESTS=ON
 %endif
 
-cmake -B %{_vpath_builddir} -LAH
+# Print all cached CMake options values; "-N" means to run in read-only mode; "-LAH" means "List Advanced Help" for each option
+cmake -B %{_vpath_builddir} -N -LAH
 
 %cmake_build