Bug 2057738

Same issue with 'mariadb' build:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=83246434

It's not a bug; actually the problem comes from the extra `.` passed to the CMake invocation out of the spec file.

See [1] for a rationale introducing this behaviour.

Removing the extra and unnecessary `.` for the CMake configure step solves the issue as tested in [2];  the `.` is actually not needed for any supported release of Fedora.


[1]  https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7001
[2]  https://koji.fedoraproject.org/koji/taskinfo?taskID=83270302


***


Example how to fix the spec file:

```
diff --git a/galera.spec b/galera.spec
index 900f3bf..e17a6da 100644
--- a/galera.spec
+++ b/galera.spec
@@ -40,7 +40,7 @@ replication engine see http://www.codership.com.
 %{set_build_flags}
 
 
-%cmake . \
+%cmake \
        -DCMAKE_BUILD_TYPE="%{?with_debug:Debug}%{!?with_debug:RelWithDebInfo}" \
        -DINSTALL_LAYOUT=RPM \
        -DCMAKE_RULE_MESSAGES:BOOL=OFF \
```

I still don't understand.

-----------

Question 1:

The default path for CMake is ".".
I mean, the %cmake macro expand to:

| ...
|   /usr/bin/cmake \
|         -S "." \
|         -B "redhat-linux-build" \
| ...

I specify the same path. So the result is actually something like:
  /usr/bin/cmake -S "." -B "redhat-linux-build" .

No matter whether the
  -S "."
is applied or my 
  .
is applied, the result should be the same as long as it points to the same path.
Why it is not ?


-----------

Question 2:

The comment here:
  https://gitlab.kitware.com/cmake/cmake/-/blob/7083b1949801dcab8b76cd3978261aca7be30c0e/Source/cmake.h#L202
Says, that no matter the order, the "-S" directive should always win.

So no matter what I specify, as long as I do not use "-S" option for it, should be completely ignored.

Why it isn't ?

-----------

I did a scratch build trying to
1/ remove the
  .
2/ change it to
  -S "."

and in both cases the build passed.

With further investigation, I still haven't found any evidence for your claim that this behavior is expected.

Somehow it didn't make it to the release notes either.


I believe the Fedora build of the CMake sofwtare does NOT behave as describe in the following source code comment:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.0-rc2/Source/cmake.h


  /**
   * Set the home directory from `-S` or from a known location
   * that contains a CMakeLists.txt. Will generate warnings
   * when overriding an existing source directory.
   *
   *  |    args           | src dir| warning        |
   *  | ----------------- | ------ | -------------- |
   *  | `dirA dirA`       | dirA   | N/A            |
   *  | `-S dirA -S dirA` | dirA   | N/A            |
   *  | `-S dirA -S dirB` | dirB   | Ignoring dirA  |
   *  | `-S dirA dirB`    | dirA   | Ignoring dirB  |
   *  | `dirA -S dirB`    | dirB   | Ignoring dirA  |
   *  | `dirA dirB`       | dirB   | Ignoring dirA  |
   */

I can see that in the new CMake version this constant is defined in CMake: 'CMAKE_INSTALL_PREFIX:PATH=/usr/local'.

However, even when I define it manually in spec (-DCMAKE_INSTALL_PREFIX:PATH=/usr), it is still redefined (I can't see where nothing is mentioned in logs), and '/usr/local' is used.

Take a look at this build.log: https://kojipkgs.fedoraproject.org//work/tasks/1277/83511277/build.log

FEDORA-2022-a48185dae6 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a48185dae6

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

Sorry about that. I've put "Related: rhbz#2059201, rhbz#2059188, rhbz#2057738" in the changelog and Bodhi closed this :(

The inconvenience of this issue grows every day.

To avoid regressions, I always put the latest content to the latest branches first.

It is even more sad that this issue came in a very unfortunate time window:
  I've got my packages updates in PRs.
  I've tested those updates, even did a scratch builds. All scratch builds passed fine, so I decided to merge and build the changes.
  And the CMake broke between the last successful Rawhide scratch build and between the first production build.
So now I have the changes merged, I have builds for all Fedora releases but Rawhide, but I can't put them in Bodhi to avoid regressions when upgrading to Rawhide.

Nearly two weeks passed since I reported this issue.
The Koschei picks up my packages here and there and since all of them use the "%cmake . " command, all of them starts to fail in Rawhide.

I also maintain several module streams of MariaDB.
While I can test them with a workaround or two, I won't be able to successfully build and submit the updates for them either.

there's 2 issues here:

1.  Arguably there's a cmake upstream bug here, behavior changed and doesn't match documentation. 

2.  There's an easy downstream fix: "don't do %cmake ."  Specifying the directory like that is at best ambiguous, and worst buggy.  Just don't do it, let %cmake macro handle it for you.

As a followup to 2, if anyone hitting this issue would like help/assistance, I'm happy to lend a hand, just drop a note mentioning which pkg(s) you'd like me to review, and I can either 'just do it' or submit PR's

These all seem affected:

FlightCrew, csdiff, libphonenumber, ledger, blas

Not all of them are doing "%cmake ." so it's not as simple as just removing the "."

e.g. libphonenumber does "%cmake cpp" instead. Should that become "cd cpp; %cmake" ?

(In reply to Jonathan Wakely from comment #13)
> These all seem affected:
> 
> FlightCrew, csdiff, libphonenumber, ledger, blas
> 
> Not all of them are doing "%cmake ." so it's not as simple as just removing
> the "."
> 
> e.g. libphonenumber does "%cmake cpp" instead. Should that become "cd cpp;
> %cmake" ?

yes , https://src.fedoraproject.org/rpms/libphonenumber/pull-request/1 

but you always can use old cmake macro behavior with : %define __cmake_in_source_build 1

more details on other migrations here:  
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#cd_builddir_.26.26_.25cmake_.._.2B_.25.28make_ninja.29_.28build.7Cinstall.29_-C_builddir

FEDORA-2022-8697087e67 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8697087e67

FEDORA-2022-8697087e67 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days