The goal of the PR is to make the build as clean as possible. Mostly this is just cleaning up pedestrian compiler warnings (e.g., unused variables). However, there is a bit of hackery to eliminate warnings from redefined preprocessor macros. See ac4b327 for details. Aside from warnings coming from redefining HYPRE_TIMING, the cpu code path now builds without warnings. The HYPRE_TIMING warnings seem to be beyond our control, at least for hypre builds with #define HYPRE_TIMING 1 in HYPRE_config.h, because mfem has #define HYPRE_TIMING in linalg/hypre.hpp (see here) which goes on to indirectly include HYPRE_config.h. I don't see a way for TPS to take care of this without modifying mfem or hypre. Building hypre with #undef HYPRE_TIMING eliminates this issue.
The goal of the PR is to make the build as clean as possible. Mostly this is just cleaning up pedestrian compiler warnings (e.g., unused variables). However, there is a bit of hackery to eliminate warnings from redefined preprocessor macros. See ac4b327 for details. Aside from warnings coming from redefining
HYPRE_TIMING, the cpu code path now builds without warnings. TheHYPRE_TIMINGwarnings seem to be beyond our control, at least for hypre builds with#define HYPRE_TIMING 1inHYPRE_config.h, because mfem has#define HYPRE_TIMINGinlinalg/hypre.hpp(see here) which goes on to indirectly includeHYPRE_config.h. I don't see a way for TPS to take care of this without modifying mfem or hypre. Building hypre with#undef HYPRE_TIMINGeliminates this issue.