CMake AnyNewerVersion -> SameMajorVersion

[aprokop]

We are not backwards compatible for version 2.0. Allowing users' 1.x code to build against 2.0 is almost 100% would lead to build failures. Would rather prevent that during configuration.

Switching to SameMajorVersion would likely be temporary, for a few 2.x releases, after which we would switch back.

An alternative to switching to SameMajorVersion would be to update CMake requirements to at least 3.19 (release 11/18/2020, so about a year older than CMake we are using right now) and do

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -136,7 +136,7 @@ configure_package_config_file(cmake/ArborXConfig.cmake.in
 )
 write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/ArborXConfigVersion.cmake
   VERSION ${ARBORX_VERSION_STRING}
-  COMPATIBILITY AnyNewerVersion
+  COMPATIBILITY AnyNewerVersion <2.0
 )
 install(FILES
   ${CMAKE_CURRENT_BINARY_DIR}/ArborXConfig.cmake

This has a benefit of not having to revisit this again later.

Note: AnyNewerVersion was introduced in #984.

[dalg24]

How about we conditionally us a version range when cmake is recent enough and we defer the actual update of our cmake minimum requirement?

[Rombur]

This means that users cannot support both 1.x and 2.x versions in their own code. That's going to be a pain.

[aprokop]

How about we conditionally us a version range when cmake is recent enough and we defer the actual update of our cmake minimum requirement?

For the current CMake, we switch to SameMajorVersion?

This means that users cannot support both 1.x and 2.x versions in their own code. That's going to be a pain.

Fair point. Do you suggest sticking with AnyNewerVersion?
Do you envision users wanting to do that? In relation to that, we should probably also provide ARBORX_VERSION macro to ease code writing depending on ArborX version.
Actually, I'm not sure exactly what you mean by this. They could do find_package(ArborX REQUIRED) without specifying version. Depending on what version they find, they could enable/disable their code.

[Rombur]

They could do find_package(ArborX REQUIRED) without specifying version

I want to be able to require a minimum version because older versions did not have ray tracing.

[aprokop]

I want to be able to require a minimum version because older versions did not have ray tracing.

Why not require ArborX 2.0? Though, that would likely only work for something small like Adamantine. Not sure about deal.II.

[Rombur]

Though, that would likely only work for something small like Adamantine. Not sure about deal.II.

Yes, I could live with SameMajorVersion in adamantine but it's a lot harder in deal.ii with all the dependencies. Someone is going to be stuck using an older version of Trilinos which means they cannot update Arborx, and so they cannot update deal.ii

[aprokop]

According to the standard ([cpp.cond].11)

After all replacements due to macro expansion and evaluations of defined-macro-expressions, has-include-expressions, and has-attribute-expressions have been performed, all remaining identifiers and keywords, except for true and false, are replaced with the pp-number 0, and then each preprocessing token is converted into a token.

This reads to me that for ARBORX_VERSION prior to #1190 would essentially be set to 0, meaning that the user code could correctly determine whether it is using version prior to 2.0 correctly even if ARBORX_VERSION is not defined.

I tested it and it indeed seems to work.

[aprokop]

So, we have three ways to proceed:

1. Require CMake 3.19 and do
   AnyNewerVersion <2.0
2. Switch to SameMajorVersion and require users to do find_package(ArborX 1.7...2.99) if they want to be able to handle both versions.
3. Leave things as they are with AnyNewerVersion.

In 2, if we start requiring CMake 3.19 in ArborX, this would essentially tell users what CMake to use implicitly.

I think option 3 is a mistake, as it break unsuspecting user's codes during compilation instead of configuration.

We need to move forward somehow.

[dalg24]

The current status quo, that is option 3, is clearly not viable.

I think that bumping our minimum cmake version requirement is not an issue. For reference, Trilinos is currently requiring 3.23. On the Kokkos side, we will likely wait until next summer and the release of 5.0.

[Rombur]

Let's go with option 2. It expresses better what is our current requirement, Option 1 and 2 are currently equivalent. They will only differ when we get to version 3 and at that time we can still decide to use option 1.

[aprokop]

So, bump CMake (to 3.19?) and go with option 2?

[Rombur]

So, bump CMake (to 3.19?) and go with option 2?

Yes, let's do that

[aprokop]

For the record, CMake 3.16 was released November 2019, CMake 3.19 November 2020, and CMake 3.22 November 2021.

Default versions:
Ubuntu 20.04: 3.16.3 (five year LTS support ends in April, 2025)
Ubuntu 22.04: 3.22.1
Frontier: 3.20.4

[aprokop]

Configuration errors in the Windows build:

CMake Error in CMakeLists.txt:
  IMPORTED_LOCATION not set for imported target "Kokkos::kokkoscore"
  configuration "RelWithDebInfo".

Weird. It used to be a warning in the Windows build. Did updating CMake made it an error?

[dalg24]

Frontier has a 3.27.9 module. I would require 3.22

[aprokop]

I would require 3.22

Why 3.22? And what's Kokkos plan for CMake version update?

[dalg24]

I would require 3.22

Why 3.22? And what's Kokkos plan for CMake version update?

Arbitrary, based on the 22.04 LTS.
Unsure but likely >= 3.22

[dalg24]

I don't quite get that change. Please explain.

[aprokop]

Admittedly, drive-by change. Instead of retaining old behavior, switch to the new one for finding boost modules. This allows to test both ways.

[dalg24]

I think the right way to do this is unconditionally setting the policy to new.
That is

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,10 +1,8 @@
 cmake_minimum_required(VERSION 3.16)
 project(ArborX CXX)

-if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.30.0)
-  message(STATUS "Setting policy CMP0167 to use FindBoost module")
-  cmake_policy(SET CMP0167 OLD)
-endif()
+# FindBoost module removed in version 3.30
+cmake_policy(SET CMP0167 NEW)

 # use gnu standard install directories
 include(GNUInstallDirs)

[aprokop]

If you do that, you will get warnings for older versions of CMake

Policy "CMP0167" is not known to this version of CMake.

[aprokop]

Windows build still fails.

[masterleinad]

Windows build still fails.

What about explicitly building for Debug via

cmake --build . --config Debug

?

[masterleinad]

I think we would rather need to specify the configuration when building ArborX since that's when it's complaining about all kind of other configurations for Kokkos missing.