core
core copied to clipboard
SCOREC
prefix cmake flags that enable optional features with PUMI
https://github.com/SCOREC/core/pull/330#discussion_r606623008
So, what if a consumer wants to use PUMI compiled with egads but they have conditional code behind HAVE_EGADS that they don't want to compile for some reason...currently they cannot do that since compile definitions are infectious. I think @cwsmith has last word on this sort of thing since he has to deal with all the xsdk people/rules.
The issue with the non-target version of add_definitions (especially in the top level cmake file) is that it will be applied to every single target and library at the current or lower sub-directory level. So, even random libraries that have nothing to do with egads are getting that compile definition added. Since these compile definitions will be infectious to anyone who uses any SCOREC target it has the potential to cause issues for down stream users.
My preference in these cases is to add a programmatic interface to check for library support (like apf::hasMETIS(), apf::hasCAP()). These calls can be scoped and do not require compile definitions via CMake or SCOREC_config.h. These checks do not allow for different types, but polymorphic interfaces like apf::Mesh*/apf::Splitter can reduce the necessity for compile-time type differences.
This is one reason why we try to have all the macros prefixed with the project name.
