v4: Use LOCATION Python FIND_STRATEGY

This update to v4 moves to use the LOCATION strategy for finding Python. This is needed as NAS (at least) has a very recent, but empty (no f2py) Python stack in the default path. Using LOCATION should limit it to the Python we want (e.g., via GEOSpyD module)

---

From CHANGELOG.md

Changed

• Move to use Python FIND_STRATEGY LOCATION by default. This is needed as NAS (at least) has a very recent, but empty (no f2py) Python stack in the default path. Using LOCATION should limit it to the Python we want (e.g., via GEOSpyD module)

---

What's Changed

• v4: Use LOCATION Python FIND_STRATEGY by @mathomp4 in #419
• GitFlow: Merge develop to main for release by @mathomp4 in #420

Full Changelog: v4.10.0...v4.11.0

v3: Use LOCATION Python FIND_STRATEGY

This update to v3 moves to use the LOCATION strategy for finding Python. This is needed as NAS (at least) has a very recent, but empty (no f2py) Python stack in the default path. Using LOCATION should limit it to the Python we want (e.g., via GEOSpyD module)

---

From CHANGELOG.md

Changed

• Move to use Python FIND_STRATEGY LOCATION by default. This is needed as NAS (at least) has a very recent, but empty (no f2py) Python stack in the default path. Using LOCATION should limit it to the Python we want (e.g., via GEOSpyD module)

---

What's Changed

• v3: Use LOCATION Python FIND_STRATEGY by @mathomp4 in #418

Full Changelog: v3.55.0...v3.56.0

v4: Fix bad MPI_STACK behavior

This release of v4 fixes some bad behavior from calling the MPI_STACK detection multiple times (due to CMake caching).

---

From CHANGELOG.md

Fixed

• Fixed bad behavior in the MPI_STACK detection on subsequent calls to DetermineMPIStack

---

What's Changed

• v4: Fix multiple MPI_STACK sets by @mathomp4 in #416
• GitFlow: Merge develop into main for 4.10 release by @mathomp4 in #417

Full Changelog: v4.9.0...v4.10.0

v3: Fix bad MPI_STACK behavior

This release of v3 fixes some bad behavior from calling the MPI_STACK detection multiple times (due to CMake caching).

---

From CHANGELOG.md

Fixed

• Fixed bad behavior in the MPI_STACK detection on subsequent calls to DetermineMPIStack

---

What's Changed

• v3: Fix multiple MPI_STACK sets by @mathomp4 in #415

Full Changelog: v3.54.0...v3.55.0

v4: Support for Python 3.12, fix for mepo status write

This release adds support for Python 3.12 f2py (which now uses meson). This requires CMake 3.24

We also fix/workaround an issue with the mepo status CMake code when run on compute nodes in certain circumstances (blobless clone, no mepo status yet run).

---

From CHANGELOG.md

Fixed

• Fixed mepo status code to allow for quiet failures. There seems to be an odd scenario on non-internet-connected machines where mepo status will fail in blobless clones of some repos. Running mepo status on a node with internet access seems to fix this.

Changed

• For F2PY3 code, set CMake Policy CMP0132 if Python is 3.12+ or higher
• Add test to see if ifort spits out the deprecation warning. Needed to hack f2py/meson
• Set minimum CMake version to 3.24 for the meson + f2py fix

---

What's Changed

• v4: Updates for meson-f2py support by @mathomp4 in #413
• GitFlow: Merge develop into main for 4.9.0 release by @mathomp4 in #414

Full Changelog: v4.8.1...v4.9.0

v3: Support for Python 3.12, fix for mepo status write

This release of v3 adds support for Python 3.12 f2py (which now uses meson). This requires CMake 3.24

We also fix/workaround an issue with the mepo status CMake code when run on compute nodes in certain circumstances (blobless clone, no mepo status yet run).

---

From CHANGELOG.md

Fixed

• Fixed mepo status code to allow for quiet failures. There seems to be an odd scenario on non-internet-connected machines where mepo status will fail in blobless clones of some repos. Running mepo status on a node with internet access seems to fix this.

Changed

• For F2PY3 code, set CMake Policy CMP0132 if Python is 3.12+ or higher
• Add test to see if ifort spits out the deprecation warning. Needed to hack f2py/meson
• Set minimum CMake version to 3.24 for the meson + f2py fix

---

What's Changed

• v3: Updates for meson-f2py support by @mathomp4 in #412

Full Changelog: v3.53.1...v3.54.0

v4: Don't try to determine MPI stack if MPI not found

ESMA_cmake itself does not require MPI, so if MPI is not found, we cannot determine an MPI stack. This release fixes that bug.

---

From CHANGELOG.md

Fixed

• Do not include DetermineMPIStack if MPI is not found

---

What's Changed

• v4: Do not determine MPI stack without MPI found by @mathomp4 in #410

Full Changelog: v4.8.0...v4.8.1

v3: Don't try to determine MPI stack if MPI not found

ESMA_cmake itself does not require MPI, so if MPI is not found, we cannot determine an MPI stack. This release fixes that bug.

---

From CHANGELOG.md

Fixed

• Do not include DetermineMPIStack if MPI is not found

---

What's Changed

• v3: Do not determine MPI stack without MPI found by @mathomp4 in #411

Full Changelog: v3.53.0...v3.53.1

v4: Output mepo status during build

This updates v4 to add a new esma_capture_mepo_status function (in esma_support/esma_mepo_status.cmake) to capture the output of mepo status --hashes when mepo was used to clone the fixture. It will output this into a file MEPO_STATUS.rc which is installed to ${CMAKE_INSTALL_PREFIX}/etc and can be used to help determine the exact state of the fixture at build time.

---

From CHANGELOG.md

Added

• Added new esma_capture_mepo_status function (in esma_support/esma_mepo_status.cmake) to capture the output of mepo status --hashes when mepo was used to clone the fixture. It will output this into a file MEPO_STATUS.rc which is installed to ${CMAKE_INSTALL_PREFIX}/etc and can be used to help determine the exact state of the fixture at build time.

---

What's Changed

• v4: Add output of mepo status by @mathomp4 in #408
• GitFlow: Merge develop into main for release by @mathomp4 in #409

Full Changelog: v4.7.0...v4.8.0

v3: Output mepo status during build

This updates v3 to add a new esma_capture_mepo_status function (in esma_support/esma_mepo_status.cmake) to capture the output of mepo status --hashes when mepo was used to clone the fixture. It will output this into a file MEPO_STATUS.rc which is installed to ${CMAKE_INSTALL_PREFIX}/etc and can be used to help determine the exact state of the fixture at build time.

---

From CHANGELOG.md

Added

• Added new esma_capture_mepo_status function (in esma_support/esma_mepo_status.cmake) to capture the output of mepo status --hashes when mepo was used to clone the fixture. It will output this into a file MEPO_STATUS.rc which is installed to ${CMAKE_INSTALL_PREFIX}/etc and can be used to help determine the exact state of the fixture at build time.

---

What's Changed

• v3: Add output of mepo status by @mathomp4 in #407

Full Changelog: v3.52.0...v3.53.0