I've appended an explicit curdir to the CMake invokation of the packages in the list you provided and triggered a build on Rawhide.  Packages should now build or be FTBFS for a different reason.

The following packages are still FTBFS, but not caused by the CMake update:

capnproto
ginac
libkml
mongo-cxx-driver
openvas-libraries

All of them have segfaulting tests on secondary arches, which seems (but is not neccessarily) to be related to GCC-9.

I looked at: https://cmake.org/cmake/help/v3.13/release/3.13.html

| 3.13.3
| CMake now checks that at least one of the source or binary directory is specified when running CMake and issues an error if
| both are missing. This has always been a documented requirement, but the implementation previously accidentally accepted cases
| in which neither are specified so long as some other argument is given, and silently used the current working directory as the source and build tree.
|
| 3.13.4
| The error added by 3.13.3 in cases that neither a source or binary directory is specified has been downgraded to a warning.
| While this was never intended, documented, nor supported behavior, some projects relied on it. The error has been downgraded
| to a warning for the remainder of the 3.13.x release series to allow a transition period, but it may become a fatal error again
| in a later release. Scripts relying on the old behavior can be trivially fixed by specifying the path to the source tree
| (even if just .) explicitly and continue to work with all versions of CMake.
|

And I assume the: https://cmake.org/cmake/help/v3.14/manual/cmake.1.html

| Generate a Project Buildsystem
|  cmake [<options>] <path-to-source>
|  cmake [<options>] <path-to-existing-build>
|  cmake [<options>] -S <path-to-source> -B <path-to-build>

explains, why the syntax
# cmake . arg1 arg2 arg3
doesn't work, while
# cmake arg1 arg2 arg3 .
does

--------------------------

However I'm not sure if I'm correct with my above findings, because some packages, e.g. "mariadb" haven't been fixed:
  https://src.fedoraproject.org/rpms/mariadb/blob/master/f/mariadb.spec#_804
  https://src.fedoraproject.org/rpms/community-mysql/blob/master/f/community-mysql.spec#_399
  https://src.fedoraproject.org/rpms/mysql-connector-odbc/blob/master/f/mysql-connector-odbc.spec#_37
while others, e.g. "mariadb-connector-c" were:
  https://src.fedoraproject.org/rpms/mariadb-connector-odbc/c/967dcef5242221c63df2f523431ade9621861bb5?branch=master
  https://src.fedoraproject.org/rpms/mariadb-connector-odbc/c/967dcef5242221c63df2f523431ade9621861bb5?branch=master
can you explain this ^ to me?

--------------------------

What I see is:
* a pretty poorly performed proven-packager intervention
  * to a set of packages which was probabbly wrongly gathered (not all cases were found)
  * without a prior PR, notice or any kind of attemp to ask the maintainers to fix it themselves
  * adding whitespace errors
* which references / is based on a BZ which
  * does not properly explain the cause
  * nor the solution

Also, you Björn, could have re-assigned this BZ to you, when you were fixing it; so it owuld be clear, that you aren't just some random guy who came and fixed it, while the asignee haven't even reacted once.

(I'd prefer the objections above to be understood as a constructive critics.)

--------------------------

So, can you please verify my findings and explain why some packages was not affected, so we can correct this hotfix?

Also following package wan't fixed.
https://src.fedoraproject.org/rpms/mariadb-connector-c/blob/master/f/mariadb-connector-c.spec#_75
And so far, I'm still speaking only of my packages.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

FEDORA-2020-c0594f0f63 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c0594f0f63

FEDORA-2020-f67faa0089 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f67faa0089

FEDORA-2020-f67faa0089 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-f67faa0089`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f67faa0089

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-c0594f0f63 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c0594f0f63`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c0594f0f63

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-f67faa0089 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Can you please clarify HOW the issue has been fixed and what's the current status now?

The release notes on this page: https://cmake.org/cmake/help/v3.17/release/3.17.html#updates
ends with 3.17.3 release so I don't know what's new in the 3.17.4.

I can see, that the "%cmake" RPM macro now expands on Rawhide to:
| ...
|   /usr/bin/cmake \
|         -S "." \
|         -B "x86_64-redhat-linux-gnu" \
| ...
so both the source dir and build dir are specified, but neither is specified on F31.

Michal,

The difference is that macro __cmake_in_source_build is undefined by default on f33+, whereas it is defined by default on prior releases.

If you want behavior to be the same on all releases, you ought to add one of these your your .spec:
%undefine __cmake_in_source_build
or
%define __cmake_in_source_build 1

Hi Rex,
I know about the change you are talking, (since it is making most of my pkgs FTBFS), but that is IMO irrelevant for this buzilla.

---

I'm not sure what was the original cause of this bug, however it made some packages FTBFS, when the package did not have specified the <path-to-source> on a correct location.
So a ProvenPackager (Björn) came along and fixed it.

But what triggered me was that he only made the change for *some* packages, which immediatelly raised questions like:
 - why is it needed in one, but not in very simmilar other ?
   - why is it needed at all when other packages can be beuilt without it.

So I started to look for answers, but did not get any. (Neither for commit message, changelog, bugzilla ticket nor CMake release notes)

I've never got any answer that would fully (not even partially) explain the need for such ProvenPackager intervention.

---

Now this Bugzilla against F31 was closed because of some change on F33 ?
I still don't see it fixed.
The macro is still expanded without "-S" "-B" on F31 & F32.
Thus the questions are still in place.

When I use any of: "%undefine __cmake_in_source_build", "%define __cmake_in_source_build 1", "%define __cmake_in_source_build 0", the result of "rpm -E %%cmake" is the same on F31.
(neither switch the behaviour to the one in current Rawhide)

---

Number of my packages utilizing CMake use the layout before the ProvenPackager intervention, number of them use the layout after it.
I don't know *which is correct* and *why*.

I cannot reproduce your findings.  When I set 
%undefine __cmake_in_source_build
in a spec, I definitely *do* see -S -B options passed to cmake (I used mariadb-connector-c.spec for this example)

the intent is that if that macro is defined, cmake will revert to legacy behavior of not using -S -B

Here's my minimal reproducer:
1/ Use mariadb-connector-c package (needed for sources)
2/ Replace it's content with:
_________________________________________________________________________________________________________________
%undefine __cmake_in_source_build

Name:           mariadb-connector-c
Version:        3.1.9
Release:        1
Summary:        XYZ
License:        XYZ
Source:         https://downloads.mariadb.org/interstitial/connector-c-%{version}/%{name}-%{version}-src.tar.gz

BuildRequires: cmake

%description
XYZ

%prep
%setup -q -n %{name}-%{version}-src

rpm -E %%cmake
exit 999

%build
%install
%files
%changelog
* Tue Aug 04 2020 Michal Schorm <mschorm> - 3.1.9-1
- XYZ
_________________________________________________________________________________________________________________

3/ run "fedpkg --release=f31 mockbuild" (or f32 mockbuild)

Now I see:
|  ...
|     /usr/bin/cmake \
|            \
|            \
|           -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
|  ...

Probabbly I'm doing something wrong. Can you spot it and correct me?

I don't think running rpm inside the .spec is a good test-case.  I'll followup with what I see running rpmbuild -bb mariadb-connector-c.spec on my f31 host.

Starting with what's currently latest in f31 branch, when I run rpmbuild -bb mariadb-connector-c.spec it shows output:

+ /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON . -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_SYSTEM_PROCESSOR=x86_64 -DMARIADB_UNIX_ADDR=/var/lib/mysql/mysql.sock -DMARIADB_PORT=3306 -DWITH_EXTERNAL_ZLIB=ON -DWITH_SSL=OPENSSL -DWITH_MYSQLCOMPAT=ON -DPLUGIN_CLIENT_ED25519=DYNAMIC -DINSTALL_LAYOUT=RPM -DINSTALL_BINDIR=bin -DINSTALL_LIBDIR=lib64 -DINSTALL_INCLUDEDIR=include/mysql -DINSTALL_PLUGINDIR=lib64/mariadb/plugin -DINSTALL_PCDIR=lib64/pkgconfig -DWITH_UNIT_TESTS=ON

with small modification:

$ git diff
diff --git a/mariadb-connector-c.spec b/mariadb-connector-c.spec
index 58f47c9..120c1ae 100644
--- a/mariadb-connector-c.spec
+++ b/mariadb-connector-c.spec
@@ -9,7 +9,7 @@
 #   The Change owners offered themselves to help fix the affected packages via ProvenPackager rights.
 #   I'm generally in favor of this change, however when I tried to adapt it, I encountered a number of issues.
 #   That's why I disabled it for now.
-%global __cmake_in_source_build 1
+%undefine __cmake_in_source_build
 #   Specifically, be aware that all subsequent call of CMake *MUST* be called with the specified builddir
 #   e.g. " cmake -B %%{__cmake_builddir} -LAH "
 #   Otherwise you will experience *really odd* behaviour. HOWEVER the "%%{__cmake_builddir}" is not suitable for use,
@@ -107,7 +107,7 @@ rm -r win win-iconv zlib examples
 # The INSTALL_* macros have to be specified relative to CMAKE_INSTALL_PREFIX
 # so we can't use %%{_datadir} and so forth here.
 
-%cmake . \
+%cmake \
        -DCMAKE_BUILD_TYPE="%{?with_debug:Debug}%{!?with_debug:RelWithDebInfo}" \
        -DCMAKE_SYSTEM_PROCESSOR="%{_arch}" \
 \

Now, rpmbuild output shows:

+ /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_SYSTEM_PROCESSOR=x86_64 -DMARIADB_UNIX_ADDR=/var/lib/mysql/mysql.sock -DMARIADB_PORT=3306 -DWITH_EXTERNAL_ZLIB=ON -DWITH_SSL=OPENSSL -DWITH_MYSQLCOMPAT=ON -DPLUGIN_CLIENT_ED25519=DYNAMIC -DINSTALL_LAYOUT=RPM -DINSTALL_BINDIR=bin -DINSTALL_LIBDIR=lib64 -DINSTALL_INCLUDEDIR=include/mysql -DINSTALL_PLUGINDIR=lib64/mariadb/plugin -DINSTALL_PCDIR=lib64/pkgconfig -DWITH_UNIT_TESTS=ON

Unfortunately, there appears to be at least one issue with this, the build eventually fails in %install:
CMake Error at x86_64-redhat-linux-gnu/unittest/libmariadb/cmake_install.cmake:481 (file):
  file INSTALL cannot find
  "/var/tmp/kdecache-rdieter/BUILDROOT/mariadb-connector-c-3.1.9-src/unittest/mytap/libcctap.so":
  No such file or directory.
Call Stack (most recent call first):
  x86_64-redhat-linux-gnu/cmake_install.cmake:158 (include)

Guessing one (or more) CmakeLists.txt is making an invalid assumption that src=build somewhere, should be fixable.

Regardless, you can keep this minor modification either way:
[rdieter@localhost mariadb-connector-c (f31)]$ git diff
diff --git a/mariadb-connector-c.spec b/mariadb-connector-c.spec
index 58f47c9..71f4350 100644
--- a/mariadb-connector-c.spec
+++ b/mariadb-connector-c.spec
@@ -107,7 +107,7 @@ rm -r win win-iconv zlib examples
 # The INSTALL_* macros have to be specified relative to CMAKE_INSTALL_PREFIX
 # so we can't use %%{_datadir} and so forth here.
 
-%cmake . \
+%cmake \
        -DCMAKE_BUILD_TYPE="%{?with_debug:Debug}%{!?with_debug:RelWithDebInfo}" \
        -DCMAKE_SYSTEM_PROCESSOR="%{_arch}" \
 \



Does that help?

If you want a better test with pure rpm, try this instead:

rpm --undefine=__cmake_in_source_build --eval %cmake

compared to:
rpm --define="__cmake_in_source_build 1" --eval %cmake

FEDORA-2020-c0594f0f63 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.