I agree with Neal.  Having a bare cmake 3.11 and a modular cmake 3.17 is only going to lead to customer confusion.  Additionally, any package that needs to use the newer version of cmake will be forced to also use modularity, regardless if it makes sense for their package.  Modularity is a useful technology, but it needs to only be used when it makes sense.

(In reply to Neal Gompa from comment #0)
> Description of problem:
> The upcoming module for CMake in RHEL 8.3 (pushed to CentOS Stream last
> night) is unnecessary and unhelpful. It is impossible to use from EPEL, as
> it's a non-default module that conflicts with the base OS version.
> 
> Please upgrade the regular CMake package instead of releasing this module.
> CMake has maintained excellent backwards compatibility since starting their
> new behavior policy in CMake 3.0, and upgrading the regular CMake package
> rather than making a module would improve the usability of this for
> downstream consumers.

Is this new behavior policy documented somewhere?

There is a document that talks about CMake policy behavior[1], and the cmake-policies(7) man page[2] describes all of the policies CMake offers.

Virtually all CMake scripts set a cmake_minimum_required[3] value, which implicitly sets the cmake_policy[1] value that configures CMake's behavior.

This mechanism is what ensures CMake remains compatible as it is upgraded, and this has been more strongly enforced since CMake 3.0.

[1]: https://cmake.org/cmake/help/latest/command/cmake_policy.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html
[3]: https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html

As mentioned over in the EPEL8 plea for newer cmake[1], I appreciate that RH is addressing the need for newer versions of cmake as more and more projects seem to be breaking with 3.11, especially CUDA based ones...  having to recompile, especially on Power, for cmake 3.14+ is time consuming/annoying.  I am a bit surprised that the default version of cmake in EL8 is but 3.11.

As Neal pointed out, if the maintainers of cmake can guarantee backwards compatibility with newer minor releases of 3.x, why not update to newer minor releases?

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1756974

It would be extremely helpful now if the non-modular CMake package is upgraded, especially because the functionality that the new Fedora macros introduced with Fedora 33 and backported to Fedora 31 and 32 requires at least CMake 3.15.

I've proposed a PR to incorporate this into the modular CMake package[1], but I really want to see this pushed into the non-modular CMake package.

I'm still trying to figure out some kind of hack to do this with CMake 3.11, and that'll likely exist for a short while (but probably not as nice as what we have for Fedora), but I'd like to eliminate it with RHEL 8.3's release.


[1]: https://git.centos.org/rpms/cmake/pull-request/1

(In reply to Quentin Haas from comment #4)
> As mentioned over in the EPEL8 plea for newer cmake[1], I appreciate that RH
> is addressing the need for newer versions of cmake as more and more projects
> seem to be breaking with 3.11, especially CUDA based ones...  having to
> recompile, especially on Power, for cmake 3.14+ is time consuming/annoying. 
> I am a bit surprised that the default version of cmake in EL8 is but 3.11.
> 

Note that CUDA projects will likely start forcing CMake 3.18 because that release includes CUDA-specific enhancements[0].

[0]: https://cmake.org/cmake/help/v3.18/release/3.18.html

Thanks everyone for the feedback, we have decided to remove this newly introduced CMake module from RHEL 8.3. Our plan (not a firm commitment at this stage) is to rebase system CMake in RHEL 8.4 instead. Hopefully this will help to address the concerns that have been raised in this bug.

The CMake module has been removed RHEL 8.3 now, closing this bug. Bug 1816874 is used to track any future work (e.g. possibly updating system CMake in RHEL 8.4).

(In reply to Tilmann Scheller from comment #9)
> The CMake module has been removed RHEL 8.3 now, closing this bug. Bug
> 1816874 is used to track any future work (e.g. possibly updating system
> CMake in RHEL 8.4).

Is there a way for Fedora/CentOS/EPEL packagers to access that bug request (https://bugzilla.redhat.com/show_bug.cgi?id=1816874), even though we are not Red Hat customers?

As many other developers and packagers, maintaining my own packages on CentOS 8 with CMake 3.11 becomes impractical. And CMake 3.17+ is already available on EPEL 7. So, offering CMake 3.11 as the latest version on CentOS 8 seems weird, to tell the least.

Apologies for the delay, I've made the bug public now. I assume you won't be able to see a lot of content yet but we'll update the bug with public comments as good as we can. Thanks!