New user self-registration is disabled due to spam. Please email eigen-core-team @ if you need an account.
Before reporting a bug, please make sure that your Eigen version is up-to-date!
Bug 1133 - Refactor Eigen for CMake subproject use.
Summary: Refactor Eigen for CMake subproject use.
Status: NEW
Alias: None
Product: Eigen
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: All All
: Normal Unknown
Assignee: Nobody
Depends on:
Reported: 2015-12-11 00:27 UTC by John McIver
Modified: 2015-12-18 05:17 UTC (History)
3 users (show)


Description John McIver 2015-12-11 00:27:27 UTC
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.

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

As I have an active requirement for this feature I have started work on a solution. It can be found at the following URL:

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.
Comment 1 Gael Guennebaud 2015-12-11 11:05:54 UTC
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?
Comment 2 John McIver 2015-12-16 05:21:22 UTC
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:

  ${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:


Would it be possible at some point to move the Eigen and unsupported directories into a single encapsulating include directory?

Thanks for your time.
Comment 3 Gael Guennebaud 2015-12-16 10:07:01 UTC
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
Comment 4 John McIver 2015-12-18 05:17:09 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.