Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/workflows/ci-tests.yml
Original file line number Diff line number Diff line change
Expand Up @@ -34,10 +34,10 @@ jobs:
matrix:
build_type: [ Debug, Release ]
config:
- job_name: gcc@13.3.1, shared, benchmarks, c++20
- job_name: gcc@13.3.1, shared, benchmarks
host_config: gcc@13.3.1.cmake
compiler_image: ${{ needs.set_image_vars.outputs.gcc_docker_image }}
cmake_opts: '-DBUILD_SHARED_LIBS=ON -DBLT_CXX_STD=c++20 -DENABLE_BENCHMARKS:BOOL=ON'
cmake_opts: '-DBUILD_SHARED_LIBS=ON -DENABLE_BENCHMARKS:BOOL=ON'
do_build: 'yes'
do_benchmarks: 'yes'
- job_name: gcc@13.3.1, shared, 32bit
Expand Down
2 changes: 2 additions & 0 deletions RELEASE-NOTES.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,6 +69,8 @@ The Axom project release numbers follow [Semantic Versioning](http://semver.org/
- Core: Deprecates the pointer-based interface to linear-, quadratic- and cubic- polynomial solvers in favor of an ArrayView-based interface

### Changed
- Axom now requires `C++20` (or newer) and will default to that if not specified via `BLT_CXX_STD`.
Configuring with `BLT_CXX_STD` set to `c++17` or lower is now a configuration error.
- Updates CMake code check targets to only use checked in files (via `git ls-files`, when available)
- CMake: Simplified execution policy logic through use of `AXOM_EXECUTION_POLICIES` variable.
- Core: Moved length unit parsing and conversion helpers into `axom::utilities`.
Expand Down
41 changes: 41 additions & 0 deletions skills/building/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,3 +64,44 @@ If the user does **not** specify a host-config file, determine the best match by
```

Use its output as the `-hc` argument (as shown in the examples above). If the user explicitly provides a host-config file/path, use that instead.

### Symlinked directories in the sandbox

If configure/build commands report that an existing path is missing, inaccessible, or outside the sandbox, check whether the source, build, install, host-config, or TPL paths include symlinks. Compare logical and physical paths with:

```bash
pwd -P
readlink -f <path>
```

Prefer physical paths resolved by `readlink -f` when invoking `config-build.py` (for `-bp`, `-ip`, `-hc`, and any explicit source/TPL paths), or restart the sandbox from the resolved workspace path. A symlinked path may appear outside the sandbox policy even when its resolved target is visible.

### MPI and Slurm in the sandbox

To run MPI-enabled commands from the sandbox, launch Codex with the `--mpi` command-line argument. This starts a Flux instance when needed. MPI through the sandbox is single-node only. If MPI or Slurm commands fail because no Flux allocation is available, stop and ask the user to restart the sandbox with `--mpi`.

On Slurm-based systems, run Slurm commands through the Flux wrapper instead of the system executable, for example:

```bash
/usr/global/tools/flux_wrappers/bin/srun -n 2 <command>
```

Loading the flux wrappers before launching the agent allows you to run the srun wrapper, e.g.
```bash
module load flux_wrappers
srun -n 2 <command>
```

When configuring builds whose MPI tests use `srun`, override CMake's MPI launcher:

```bash
./config-build.py -hc "$(./skills/building/scripts/determine_host_config)" -DMPIEXEC_EXECUTABLE=/usr/global/tools/flux_wrappers/bin/srun
```

### Shroud in the sandbox

If CMake configuration has trouble with Shroud in the sandbox, unset the cached Shroud executable at configure time:

```bash
./config-build.py -hc "$(./skills/building/scripts/determine_host_config)" -USHROUD_EXECUTABLE
```
5 changes: 3 additions & 2 deletions src/CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -108,8 +108,9 @@ if ("${PROJECT_SOURCE_DIR}" STREQUAL "${CMAKE_SOURCE_DIR}")
endif()

if("${BLT_CXX_STD}" STREQUAL "c++98" OR "${BLT_CXX_STD}" STREQUAL "c++11"
OR "${BLT_CXX_STD}" STREQUAL "c++14" )
message(FATAL_ERROR "Axom requires BLT_CXX_STD to be 'c++17' or above.")
OR "${BLT_CXX_STD}" STREQUAL "c++14"
OR "${BLT_CXX_STD}" STREQUAL "c++17" )
message(FATAL_ERROR "Axom requires BLT_CXX_STD to be 'c++20' or above.")
endif()

include(${BLT_SOURCE_DIR}/SetupBLT.cmake)
Expand Down
1 change: 1 addition & 0 deletions src/axom/config.hpp.in
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,7 @@
#cmakedefine AXOM_USE_LUMBERJACK
#cmakedefine AXOM_USE_MINT
#cmakedefine AXOM_USE_MIR
#cmakedefine AXOM_USE_MULTIMAT
#cmakedefine AXOM_USE_PRIMAL
#cmakedefine AXOM_USE_QUEST
#cmakedefine AXOM_USE_SIDRE
Expand Down
4 changes: 4 additions & 0 deletions src/axom/core/utilities/About.cpp.in
Original file line number Diff line number Diff line change
Expand Up @@ -99,6 +99,10 @@ void about(std::ostream &oss)
comps.push_back("mir");
#endif

#ifdef AXOM_USE_MULTIMAT
comps.push_back("multimat");
#endif

#ifdef AXOM_USE_PRIMAL
comps.push_back("primal");
#endif
Expand Down
2 changes: 1 addition & 1 deletion src/axom/quest/interface/python/setup.py.in
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ quest = Extension(
srcdir,
os.path.join(binarydir, 'include'),
os.path.join(mpidir, 'include')],
extra_compile_args=['-std=c++11'], # gcc flag
extra_compile_args=['-std=c++@CMAKE_CXX_STANDARD@'], # gcc flag
libraries=['axom_quest'],
library_dirs=[libdir],
# rpath needed to find libquest.so during import
Expand Down
4 changes: 2 additions & 2 deletions src/docs/sphinx/coding_guide/sec11_portability.rst
Original file line number Diff line number Diff line change
Expand Up @@ -24,10 +24,10 @@ restricted.
Portability
--------------------------------------------------------------------

Nothing beyond C++17
Nothing beyond C++20
^^^^^^^^^^^^^^^^^^^^

11.1 C++ language features beyond standard C++17 **must not** be used unless
11.1 C++ language features beyond standard C++20 **must not** be used unless
reviewed by the team and verified that the features are supported by all
compilers we need to support.

Expand Down
16 changes: 9 additions & 7 deletions src/docs/sphinx/quickstart_guide/config_build.rst
Original file line number Diff line number Diff line change
Expand Up @@ -26,8 +26,9 @@ Requirements, Dependencies, and Supported Compilers
Basic requirements:
~~~~~~~~~~~~~~~~~~~

* C++ compiler with C++17 support at a minimum
* CMake with a minimum required version of 3.14 for CPU-only and CUDA builds,
* C++ compiler with C++20 support at a minimum
* CMake with a minimum required version of 3.14 for CPU-only builds,
a minimum version of 3.18 when building with CUDA support,

@rhornung67 rhornung67 Aug 24, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the logic in the top-level CMakeLists.txt file for CUDA builds requiring CMake 3.18+. However, this comment seems to conflict with that: https://github.com/llnl/axom/blob/develop/src/CMakeLists.txt#L13

Is this still an issue; i.e., CUDA build is broken depending on which CMake version is used?

Also, should the choice of CMake min version be done the same way for all cases; i.e., using cmake_minimum_required. We have some comments about not using that. Seems confusing to me how we handle different cases.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair -- I think that the following two statements are true:
(a) the CMake version for CUDA needs to be at least 3.18,
(b) we need to set the cmake_minimum_required to 3.14 at the top of src/CMakeLists.txt for CUDA builds. The cmake_minimum_version function affects the CMake policies and their default values.

Presumably, this will be improved once llnl/blt#769 is merged (?)

@white238 -- should this docs change be rolled back or clarified? Alternatively, should we add a clarifying note to https://github.com/llnl/axom/blob/develop/src/CMakeLists.txt#L13 to reflect the actual CMake requirement for CUDA as opposed to the listed cmake_minimum_version

(Also, please let me know if I got this wrong)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CMake 3.18 + CUDA + c++20 actually is a failure due to CMake not knowing that CUDA supports C++20 that early in CMake. It was set to this because many moons ago we noticed that it was changing cmake policies based on the cmake_minimum_required and this caused failures. We should reevaluate this at some point.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Should I add a note here or in src/CMakeLists.txt and/or roll back the changes in this paragraph?
Or is it good for now, and we'll revisit in the future?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it passes all CI checks, I say let's go with as is for now. Please make an issue to reevaluate so we don't forget to do that.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the following issue for this: #1965

and a minimum version of 3.21 when building with HIP support
* Fortran Compiler (optional)
* Python 3.8 at a minimum for python bindings (optional)
Expand Down Expand Up @@ -240,10 +241,11 @@ For more information, see `BLT host-config documentation <https://llnl-blt.readt
C++20 and CUDA
~~~~~~~~~~~~~~~

C++20 support in Axom is enabled by setting the ``BLT_CXX_STD`` variable in a
host-config file to ``c++20``. If you get a configuration error indicating that
Axom requires ``C++20``, and CUDA sources are compiled against the same standard.
CMake first supported ``CUDA_STANDARD 20`` for an actual compiler in version 3.18,
so CUDA-enabled builds require CMake 3.18 or newer. Axom's build system checks this
and emits a fatal error otherwise. If you get a configuration error indicating that
CUDA does not support C++20, the solution is to use a more recent CMake version.
Consult CMake's release notes to find a version that supports C++20 and CUDA.

Python helper script
~~~~~~~~~~~~~~~~~~~~
Expand Down Expand Up @@ -455,8 +457,8 @@ options to be provided, which are summarized in the following table.
+------------------------------+------------------------------------------+

.. note :: To configure the version of the C++ standard, you can supply one of the
following values for **BLT_CXX_STD**: 'c++17' or 'c++20'.
Axom requires at least 'c++17', the default value.
following values for **BLT_CXX_STD**: 'c++20' or newer.
Axom requires at least 'c++20', the default value.


Tools and features primarily intended for developers
Expand Down
22 changes: 11 additions & 11 deletions src/examples/radiuss_tutorial/lesson_00/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
In this lesson, we will develop a simple application that uses an installed version of Axom.
Specifically, we will print the version of Axom and some of its configuration properties.

> :information_source: Our examples use the ``C++17`` standard since that's Axom's current version.
> :information_source: Our examples use the ``C++20`` standard since that's Axom's current version.

We will also be using the [fmt](https://fmt.dev/latest/index.html) library for string formatting, which Axom uses internally and vendors for its users.
The vast majority of ``fmt`` has been included in recent C++ standards, starting with ``C++20``. See also the [fmt cheat sheet](https://hackingcpp.com/cpp/libs/fmt.html).
Expand Down Expand Up @@ -84,15 +84,15 @@ std::cout << axom::fmt::format("Version: {}", axom::getVersion()) << "\n\n";
This includes the major, minor and patch version of Axom as well as the git SHA (when available).
The above command might produce something like:
```
Version: v0.9.0-f5b5b5d66
Version: v0.14.0-b26e10df2
```

The version is also available as compiler defines in ``axom/config.hpp``. The following corresponds to the above version:
```cpp
#define AXOM_VERSION_MAJOR 0
#define AXOM_VERSION_MINOR 9
#define AXOM_VERSION_MINOR 14
#define AXOM_VERSION_PATCH 0
#define AXOM_VERSION_FULL "v0.9.0"
#define AXOM_VERSION_FULL "v0.14.0"
```

## Checking details about the Axom configuration
Expand All @@ -114,18 +114,18 @@ We can run the application using:
Its output should look something like:
```
Axom information:
AXOM_VERSION_FULL: v0.9.0
AXOM_VERSION_FULL: v0.14.0
AXOM_VERSION_MAJOR: 0
AXOM_VERSION_MINOR: 9
AXOM_VERSION_MINOR: 14
AXOM_VERSION_PATCH: 0
AXOM_GIT_SHA: f5b5b5d66
AXOM_GIT_SHA: b26e10df2
Compiler Settings:
C++ Standard: c++17
Size of axom::IndexType: 4
C++ Standard: c++20
Size of axom::IndexType: 8
Active programming models: { mpi;openmp }
Available components: { core;inlet;klee;lumberjack;mint;primal;quest;sidre;slam;slic;spin }
Available components: { core;bump;inlet;klee;lumberjack;mint;mir;multimat;primal;quest;sidre;sina;slam;slic;spin }
Active built-in dependencies: { CLI11;fmt;sol;sparsehash }
Active external dependencies: { adiak;caliper;conduit;hdf5;lua;mfem;raja;umpire }
Active external dependencies: { adiak;caliper;conduit;hdf5;lua;mfem;opencascade;raja;scr;umpire }
```

> :clapper: Run the example for this lesson
Expand Down
22 changes: 10 additions & 12 deletions src/examples/shaping_tutorial/lesson_00/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -89,7 +89,7 @@ graph LR

Let's get our feet wet with a first example that uses an installed version of Axom. Specifically, we will print the version of Axom and some of its configuration properties.

> :information_source: Axom requires ``C++17`` or higher. This example uses the ``C++20`` standard.
> :information_source: Axom requires ``C++20`` or higher. This example uses the ``C++20`` standard.

> :memo: For details about configuring and installing Axom, see the [Zero-to-Axom Installation Guide](https://axom.readthedocs.io/en/develop/zero_to_axom/index.html)

Expand Down Expand Up @@ -167,15 +167,15 @@ std::cout << axom::fmt::format("Version: {}", axom::getVersion()) << "\n\n";
This includes the major, minor and patch version of Axom as well as the git SHA (when available).
The above command might produce something like:
```
Version: v0.12.0-fd04d6d3d
Version: v0.14.0-b26e10df2
```

The version is also available as compiler defines in ``axom/config.hpp``. The following corresponds to the above version:
```cpp
#define AXOM_VERSION_MAJOR 0
#define AXOM_VERSION_MINOR 12
#define AXOM_VERSION_MINOR 14
#define AXOM_VERSION_PATCH 0
#define AXOM_VERSION_FULL "v0.12.0"
#define AXOM_VERSION_FULL "v0.14.0"
```

## Checking details about the Axom configuration
Expand All @@ -198,20 +198,18 @@ Its output should look something like:

```
Axom information:
AXOM_VERSION_FULL: v0.12.0
AXOM_VERSION_FULL: v0.14.0
AXOM_VERSION_MAJOR: 0
AXOM_VERSION_MINOR: 12
AXOM_VERSION_MINOR: 14
AXOM_VERSION_PATCH: 0
AXOM_GIT_SHA: fd04d6d3d
AXOM_GIT_SHA: b26e10df2
Compiler Settings:
C++ Standard: c++20
Size of axom::IndexType: 8
Active programming models: { mpi;openmp }
Available components: { core;bump;inlet;klee;lumberjack;mint;mir;
primal;quest;sidre;sina;slam;slic;spin }
Active programming models: { mpi;openmp }
Available components: { core;bump;inlet;klee;lumberjack;mint;mir;multimat;primal;quest;sidre;sina;slam;slic;spin }
Active built-in dependencies: { CLI11;fmt;sol;sparsehash }
Active external dependencies: { adiak;c2c;caliper;conduit;hdf5;lua;
mfem;raja;scr;umpire }
Active external dependencies: { adiak;c2c;caliper;conduit;hdf5;lua;mfem;opencascade;raja;scr;umpire }
```


Expand Down