1. SIGMA Avatar SIGMA
  2. Components
  3. MOAB
  4. Issues

CMake Eigen configuration

Issue #88 resolved
Patrick Shriwise created an issue

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)

  1. Paul Wilson

    Presumably something needs to be added in the template from which MOABConfig.cmake is generated such as MOABConfig.cmake.cmake and/or MOABConfig.cmake.in

  2. Patrick Shriwise 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.

  4. Vijay M

    The MOABConfig.cmake.cmake should have an entry for EIGEN_INCLUDE_DIR after configuration. Wouldn't that be enough for downstream apps ?

  5. Paul Wilson

    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.

  6. Vijay M

    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.

  7. Paul Wilson

    I'm noticing a couple of things:

    1. MOABConfig.cmake.in adds EIGEN3_INCLUDES to MOAB_PACKAGE_INCLUDES but MOABConfig.cmake.cmake does not. I think this is effectively the MOAB_THIRDPARTY_INCLUDES that you are referring to.

    2. I don't see anywhere that EIGEN3_INCLUDES is defined. I looked at FindNetCDF.cmake (selected arbitrarily) and noticed that it does define NETCDF_INCLUDES that also gets added to MOAB_PACKAGE_INCLUDES, so that appears to be the model.

    3. MOAB_PACKAGE_INCLUDES is never added to any other variable - should downstream app developers be instructed to add this to their build workflow?

  8. Paul Wilson

    Also note that MOAB_PACKAGE_LIBS is currently being appended to MOAB_LIBRARIES, so by analogy would it might be reasonable for MOAB_PACKAGE_INCLUDES to be appended to MOAB_INCLUDE_DIRS?

  9. Vijay M

    That's exactly what we want then. We should add EIGEN_INCLUDE_DIR to MOAB_PACKAGE_INCLUDES. I must have missed that variable when looking at the file earlier. Adding -I@EIGEN_INCLUDE_DIR@ to MOAB_PACKAGE_INCLUDES should suffice.

  12. Vijay M

    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

  13. Paul Wilson

    Yes - my plan was to try and make sure they have consistent behavior since I think that will mostly take care of it.

  14. Paul Wilson

    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):

    1. the CMake version does not include DAMSEL or CCMIO
    2. autotools version does not add MPI_CXX_LIBRARIES to MOAB_PACKAGE_LIBS
    3. the autotools version has an EXPORT_LDFLAGS variable that gets passed around and added to MOAB_PACKAGE_LIBS
  15. Paul Wilson

    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...

  16. Vijay M

    @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.

  20. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
–
Version
5.0.0
Votes
0
Watchers
1