👋 @shimwell @ahnaf-tahmid-chowdhury @gonuke @pshriwise as you all reviewed PR #969, which was the last time

was touched, can I get one of you to approve a CI run on this before I request review (in the event that I might want to clear or clarify a few things first)?

Thanks to whoever enabled the CI. 👍

The macOS build tests are failing but given

and

-- The C compiler identification is AppleClang 17.0.0.17000013
-- The CXX compiler identification is AppleClang 17.0.0.17000013
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Looking for stdlib.h
-- Looking for stdlib.h - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for memory.h
-- Looking for memory.h - found
-- Check if the system is big endian
-- Searching 16 bit integer
-- Check size of unsigned short
CMake Error: File /opt/homebrew/share/cmake/Modules/TestEndianess.c.in does not exist.
-- Check size of unsigned short - done
CMake Error at config/TestBigEndian.cmake:39 (CONFIGURE_FILE):
-- Using unsigned short
  CONFIGURE_FILE Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:168 (TEST_BIG_ENDIAN)


CMake Error at config/TestBigEndian.cmake:43 (FILE):
  FILE failed to open for reading (No such file or directory):

    /Users/runner/work/DAGMC/moab/bld/CMakeFiles/CMakeTmp/TestEndianess.c
-- Configuring incomplete, errors occurred!
Call Stack (most recent call first):
  CMakeLists.txt:168 (TEST_BIG_ENDIAN)


CMake Error at /Users/runner/work/DAGMC/moab/bld/CMakeFiles/CMakeTmp/CMakeLists.txt:21 (target_sources):
  Cannot find source file:

    /Users/runner/work/DAGMC/moab/bld/CMakeFiles/CMakeTmp/TestEndianess.c


CMake Error at /Users/runner/work/DAGMC/moab/bld/CMakeFiles/CMakeTmp/CMakeLists.txt:20 (add_executable):
  No SOURCES given to target: cmTC_2e25d


CMake Error at config/TestBigEndian.cmake:46 (TRY_COMPILE):
  Failed to generate test project build system.
Call Stack (most recent call first):
  CMakeLists.txt:168 (TEST_BIG_ENDIAN)


make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.

this seems to be unrelated to this PR specifically and more issues with what's currently installed by the Homebrew cmake on the runner(?).

👋 @shimwell @ahnaf-tahmid-chowdhury @gonuke @pshriwise this is ready for review now (and needs a CI approval again). Let me know if you have any questions. 👍

I wasn't aware of this CMake policy. I am curious whether what the value of adding the max version is? I suppose if a newer version makes our CMake configuration break, this would detect/avoid that?

@gonuke The short version of this is somewhat the opposite of your statement. cmake_minimum_required(VERSION) means "use CMake policy of ==VERSION" and not "use CMake policy >=VERSION". Newer versions of CMake (the software release) don't break old CMake builds (unless you have custom CMake files that hardcode things), but they do remove outdated policies. Using policy_max is actually about keeping your CMake builds building for as long as possible, so that when new CMake releases drop outdated policies you have not pinned your project to a policy that is no longer in support.

Here's a much longer summary taken from my colleague Henry Schreiner on a GitLab project MR (I'm quoting exactly here, so the CMake versions in question will be different):

... many times packages were fine with, or even wanted the better defaults with newer versions, but they also wanted to support older CMake versions. This is where the upper bound comes in: You now set two “minimums”: the real (lower) minimum and the (upper) minimum based on what you’ve tested with. The defaults (policies) will be set to the highest value possible between the two values. So if you have cmake_minimum_required(VERSION 3.15...3.26) , then if you run with CMake 3.14, it’s an error, if you run with CMake 3.21, it uses 3.21's policies, and if you run with CMake 3.29, it uses 3.26's policies.

Eventually, they want to drop old policies. CMake 4.0 doesn’t support policies older than 3.5, and warns on policies older than 3.10. So cmake_minimum_required(VERSION 2.8...3.15) is perfectly fine; it sets the policies to 3.15 on CMake 4.0. But cmake_minimum_required(VERSION 3.4) is not, as that sets the policies to 3.4 on newer CMake’s, and those policies have been removed in 4.0. You should set the upper minimum to the highest value you can to ensure your code builds for as long as possible.

On the other hand, it creates a maintenance burden to keep updating this periodically.

In practice this is low effort in that builds are ideally tested with latest (or at least modern) releases of tooling, and so when a new major or modern version of CMake comes out you bump the policy_max up to that version and test, and that will eventually make its way out into a release. The releases should build indefinitely into the future as long as you're able to get a distribution of CMake that has supported policies between <min> and <policy_max>. When some future version of CMake drops these (like how CMake v4.0 dropped policies older than 3.5) you are then bound to use an older version of CMake to build those older releases. As CMake drops policies rather slowly this means that having a range can give you a much extended build support window of many years compared to having only <min>.