As the upcoming xSDK version 1.0.0 is currently tested with precice@develop, we should prepare an update for the precice Spack package before merging this.

The only violation I can spot right now is PRECICE_ENABLE_LIBBACKTRACE, or should we go for PRECICE_LIBBACKTRACE_STACKTRACES?

I also don't have any good idea on how to handle this. Does it toggle a feature, or choose between two different dependencies?

Does it toggle a feature, or choose between two different dependencies?

It toggles more of a developer feature, which enables the generation of stacktraces (otherwise the stacktraces are just masked and unusable).

More on a side-note: do we also keep the default for all FEATURE=ON ? Some of them are more in use for corner-cases. Some projects use autodetection mechanisms for such purposes. Any opinions on this?

More on a side-note: do we also keep the default for all FEATURE=ON ? Some of them are more in use for corner-cases. Some projects use autodetection mechanisms for such purposes. Any opinions on this?

As long as the user receives a clear message "PETSc not found - Set PRECICE_FEATURE_PETSC_MAPPING=OFF", I would be fine with the current behavior. The autodetection could lead to silently disabling some features, which may be making reproducibility more complicated.

I like the new format. The feature prefix really makes them easier to detect in ccmake too.

Some projects use autodetection mechanisms for such purposes. Any opinions on this?

Autodetection is a huge pain as your entire system leaks into your builds, making them non-reproducible. I already ran into this with some other projects. Explicit options and hard errors are the way to go. CMake has some support for this, but it is super confusing from the developer and user perspective.

libbacktrace is intended to be a developer tool, so I wouldn't make it too prominent. Technically, it toggles more extensive stacktraces, which could be seen as a feature.

Some TODOs:

• Update cmake/GenerateVersionInformation.cmake (output of precice-tools version)
• Update 'CMakePresets.txt`

I have a spack branch ready now. So, its not blocking a merge.

Update 'CMakePresets.txt`

I don't see any update requirements in the CMakePresets.json

Oops right.

So it's just a question what to do with the libbacktrace now.

So it's just a question what to do with the libbacktrace now.

Yes, for me, libbacktrace fits more into the category of developer features and not into our FEATURE category. Googletest might eventually end-up in the same. I would either

• PRECICE_ENABLE_LIBBACKTRACE -> leave it as it is right now
• PRECICE_DEVEL_LIBBACKTRACE -> to indicate development features
• PRECICE_CONFIGURE_LIBBACKTRACE -> in analogy to our package generation

Once we agreed here, I would merge this PR, as I understand that a corresponding spack patch is ready.

* `PRECICE_ENABLE_LIBBACKTRACE` -> leave it as it is right now

The ENABLE_ prefix sounds a bit arbitrary now. Why should this be prefixed, but not, e.g., PRECICE_MPI_MAPPING?

* `PRECICE_DEVEL_LIBBACKTRACE` -> to indicate development features

This is the option I like the most, even though I would find it hard to argue that it is only a feature for developers of preCICE. I could imagine that people use stacktraces when debugging their codes, which use preCICE. But no real objection here.

* `PRECICE_CONFIGURE_LIBBACKTRACE` -> in analogy to our package generation

I thought that the package generation was really that we prepare the configuration for the package generation. The CONFIGURE_ here sounds strange to me (again: why for this but not also for everything else).

This is the option I like the most, even though I would find it hard to argue that it is only a feature for developers of preCICE. I could imagine that people use stacktraces when debugging their codes, which use preCICE. But no real objection here.

I mean we can also go for PRECICE_FEATURE_LIBBACKTRACE_STACKTRACES if you argue this way.

This is the option I like the most, even though I would find it hard to argue that it is only a feature for developers of preCICE. I could imagine that people use stacktraces when debugging their codes, which use preCICE. But no real objection here.

I mean we can also go for PRECICE_FEATURE_LIBBACKTRACE_STACKTRACES if you argue this way.

Sounds consistent, I guess let's do that.