FEATURE OVERVIEW: Add support to Eigen CMake so that it can be included into a CMake build tree by using the CMake command "add_subdirectory( eigen )". Eigen currently uses CMake to produce a standalone build solution. However, in a number of development cases it is preferable to add third-party packages to the build tree. With CMake this allows for full CMake target dependent builds, straight forward unit-testing on integration platforms, and reduced external library management overhead. GOALS: * Maintain full current build functionality. * Both the standalone and submodule implementation share all CMake code, with minimal changes. * A copy of the Eigen headers will be placed in the the build area in such a way that standalone and submodule based builds are interchangeable, i.e., CMake changes not the include paths. IMPLEMENTATION: As I have an active requirement for this feature I have started work on a solution. It can be found at the following URL: https://bitbucket.org/jkmciver/eigen-cmake-subproject Currently the implementation does not handle unsupported headers. Additionally a minimum version push to CMake 3.3.1 was required in order to allow dependencies to be associated with interface targets.
Since Eigen is header-only and does not require any pre-configuration step, I don't see much use case for that. Perhaps to make "make install" installs Eigen's headers too?
The convenience I was attempting to provide was a reduction in the overall include space for our project to only the supported headers (and unsupported). For example in my project's environment Eigen resides under third-party/eigen. Since we are not installing Eigen as a pre-build step outside of our CMake, and I have dependencies on Eigen during build, this results in something analogous to the following as Eigen is as you pointed out "header-only": include_directories( ${CMAKE_SOURCE_DIR}/third-party/eigen ) If I wanted to restrict functionality to that provided by the header-only install targets I could specify: include_directories( ${CMAKE_SOURCE_DIR}/third-party/eigen/Eigen ${CMAKE_SOURCE_DIR}/third-party/eigen/unsupported ) However, that would cause a difference from how the FindEigen3.cmake CMake module specifies the include path. We generally try to keep our relative paths aligned to match the standalone install of a package so if a customer wants to use their copy we disable ours in the build tree. An alternate solution would be to move the header directories "Eigen" and "unsupported" into a common directory thus allowing: include_directories( ${CMAKE_SOURCE_DIR}/third-party/eigen/include ) And resulting in the following two paths: eigen/include/Eigen eigen/include/unsupported Would it be possible at some point to move the Eigen and unsupported directories into a single encapsulating include directory? Thanks for your time.
This can easily be done in your own cmake, using cmake commands to either: - copy the two directories - create symlinks - perform portable calls similar to mkdir -p eigen/build ; cd eigen/build ; cmake .. -DCMAKE_INSTALL_PREFIX=../include ; make install
Create symlinks: I support Windows build environments as well and symlinks are not portable. Copy the two directories: My proposed solution does exactly that, but it puts them in eigen build space under a directory called "include". The copy targets are *only* created if the project is being included as a subproject in the CMake build tree. If Eigen is being built in the normal fashion for direct installation the copy targets are never generated. The reason I prefer the copy targets are: 1. If the source is changed the project automatically copies them. 2. It can be linked to an interface target. I see that others might be interested in a similar feature as Bug 773 makes a point about finding "Eigen either in the build tree or in the install tree". However, my proposed solution could circumvent the use of find_package calls as an "interface target" could be used instead.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1133.