Chris White

- [ ] Fat Binaries: eg. --offload-arch='gfx942,gfx940,gfx90a' - [ ] Rocm/5.7.1 with rocmcc-5.7.1-cce-17.0.0-magic - [ ] Rocm/5.7.1 with cce-17.0.0-magic

We are currently running duplicate pipelines in Azure under axom/axom and healy22. We should fix this.

https://axom.readthedocs.io/en/develop/#component-level-dependencies There used to be a picture showing the dot graph. It is apparently broken.

It finds camp -> raja -> umpire, shouldn't this be failing because of the previous reasons?

This needs to a general clean up. We should move fully to a variable that auto-detects the install prefix and verify that all our dependencies are being loaded properly.

Handle MFEM's CMake build system better

1

If MFEM is built using their CMake build system, Axom does not export or recreate the `axom::mfem` target for downstream users. Serac does this but I forgot to move this...

We need a pipeline that runs on docker/LC that tests the build through `scripts/spack/packages/axom/package.py`. This should be limited to only building Axom itself for time constraints and not build the...

This CMake target property is inherited by anyone that uses the exported camp targets. In my case this is used by Axom via RAJA and causes the following very helpful...

A user attempted to use Uberenv outside of a repo that had a config file. It naturally didn't find it but the error message was confusing. We should harden this...

I've ran into cases where the `spack.yaml` is generated but wasn't copied due to failures. We should try to always do the copying. https://github.com/LLNL/uberenv/blob/991a9cef316d313b660811804692f305da9bb346/uberenv.py#L933-L934