CMake Eigen configuration
Applications using CMake that depend on MOAB can sometimes miss the necessary location of Eigen3 headers. This can be fixed by ading EIGEN_INCLUDE_DIR
to the MOAB_INCLUDE_DIRS
variable in the MOABConfig.cmake
file, but I'm not sure this is the correct fix. Can someone take a look?
I've attached an example of this below.
Comments (19)
-
-
reporter Likely both, yes. I'm not sure if it would be as simple as adding
EIGEN_INCLUDE_DIR
to both configurations or not. I'll need to take a closer look. -
reporter -
assigned issue to
-
assigned issue to
-
The MOABConfig.cmake.cmake should have an entry for
EIGEN_INCLUDE_DIR
after configuration. Wouldn't that be enough for downstream apps ? -
EIGEN_INCLUDE_DIR
is set correctly, but downstream apps don't know that they need to include it. It needs to be added to a variable that they use to set their includes. -
We could append it to the MOAB_INCLUDE_DIRS list, but I wanted to keep 3rd party dependencies separate. I am open to suggestions however. We could create a
MOAB_THIRDPARTY_INCLUDES
variable that stores all upstream include flags. -
I'm noticing a couple of things:
-
MOABConfig.cmake.in
addsEIGEN3_INCLUDES
toMOAB_PACKAGE_INCLUDES
butMOABConfig.cmake.cmake
does not. I think this is effectively theMOAB_THIRDPARTY_INCLUDES
that you are referring to. -
I don't see anywhere that
EIGEN3_INCLUDES
is defined. I looked atFindNetCDF.cmake
(selected arbitrarily) and noticed that it does defineNETCDF_INCLUDES
that also gets added toMOAB_PACKAGE_INCLUDES
, so that appears to be the model. -
MOAB_PACKAGE_INCLUDES
is never added to any other variable - should downstream app developers be instructed to add this to their build workflow?
-
-
Also note that
MOAB_PACKAGE_LIBS
is currently being appended toMOAB_LIBRARIES
, so by analogy would it might be reasonable forMOAB_PACKAGE_INCLUDES
to be appended toMOAB_INCLUDE_DIRS
? -
That's exactly what we want then. We should add
EIGEN_INCLUDE_DIR
toMOAB_PACKAGE_INCLUDES
. I must have missed that variable when looking at the file earlier. Adding-I@EIGEN_INCLUDE_DIR@
toMOAB_PACKAGE_INCLUDES
should suffice. -
I've found a number of other inconsistencies, I'll try to PR something in a few minutes.
-
-
assigned issue to
-
assigned issue to
-
Can you also look at MOABConfig.cmake.in and MOABConfig.cmake.cmake.in to make sure they both have similar/consistent behavior ? Or if you focus on CMake, I can look at the autoconf and enhance your branch a little later.
I'm busy this morning and won't have time to look at it again until later in the day
-
Yes - my plan was to try and make sure they have consistent behavior since I think that will mostly take care of it.
-
I just pushed
gonuke/pass_along_eigen
and am using pipelines to test it.Some things I don't have time/expertise to resolve (will make issues):
- the CMake version does not include DAMSEL or CCMIO
- autotools version does not add
MPI_CXX_LIBRARIES
toMOAB_PACKAGE_LIBS
- the autotools version has an
EXPORT_LDFLAGS
variable that gets passed around and added toMOAB_PACKAGE_LIBS
-
On a related note, could/should there be a test for building some third party app (Hello World-like) that ensures that this all works? Might be hard to construct such a test to cover all the use cases...
-
@gonuke Can you raise a separate request for a Hello World-like app to test configuration. I have something along these lines but would like to address the issue separately. Also if we have addressed the main "CMake Eigen" issue, please close issue
#88. -
I just PR'ed my branch to address this...
-
Added
#95to capture "hello world" like issue -
- changed status to resolved
All the requests in Issue
#88have been addressed in MOAB 5.1 release. - Log in to comment
Presumably something needs to be added in the template from which
MOABConfig.cmake
is generated such asMOABConfig.cmake.cmake
and/orMOABConfig.cmake.in