It turns out that one of Dakota's external packages does this:
And then somebody includes that and then (indirectly) Kokkos_Traits.hpp.
Lack of compilation ensues.
Dakota lead has already been alerted.
Uhm I would argue Dakota should fix this. Having a global define named "OK" seems like a very bad idea.
I agree @crtrott . Courtesy of @csiefer2 we know this is caused by an include chain that ends in a Dakota-included third-party library. Specifically: dakota/packages/external/acro/packages/utilib/src/utilib/_generic.h This header declares a number of other very generically named preprocessor and symbols, only a few of them namespaced.
A workaround is to disable Dakota's Acro sub-package by setting the CMake variable HAVE_ACRO:BOOL=FALSE.
I'm working with Chris to test a patch to the TPL and if it works, will address some of the other pernicious global defines. I'm sure others will remain, but we can at least get the worst of them. It would also be good for Dakota to manage its includes more judiciously to avoid this bleed; perhaps we can try that in addition.
Most helpful comment
Uhm I would argue Dakota should fix this. Having a global define named "OK" seems like a very bad idea.