Eigen::all Eigen::placeholders::all Eigen::indexing::all not available in example project
Opened this issue · 9 comments
Hi,
I wanted to update my old codebase so it works with new libigl buildsystem. My code uses Eigen::all
almost in every function but when compiling i get the error:
no member named 'all' in namespace 'Eigen'
As a first debugging step I downloaded the libigl example project and built it (which worked fine). After that I added the following line of code after this line of to the main
function of libigl example project:
std::cout << F(Eigen::all, 0) << std::endl;
With this line added i get the same error:
error: no member named 'all' in namespace 'Eigen'
std::cout << F(Eigen::all, 1) << std::endl;
~~~~~~~^
I found online several posts that say that Eigen::all
changed to Eigen::placeholders::all
or even Eigen::indexing::all
. All of them i tried but the error still exists.
The eigen documnetation still suggests using all
(see here) so i guess the error somehow is in the build system.
Thanks a lot for help in advance!
Update:
I manage to build using Eigen::all
as pointed out above when I include eigen "manually".
With terminal inside example project folder i first mkdir external && cd external && git clone https://gitlab.com/libeigen/eigen.git
.
After that i exchange the example projects CMakeLists
file to
cmake_minimum_required(VERSION 3.16)
project(example)
list(PREPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)
# Important to set CXX standard to 17 otherwise eigen cannot be built
set(CMAKE_CXX_STANDARD 17)
# Add your project files
file(GLOB SRC_FILES *.cpp)
add_executable(${PROJECT_NAME} ${SRC_FILES})
# make this dance to avoid libigl using its own eigen
add_library(Eigen3_Eigen INTERFACE)
add_library(Eigen3::Eigen ALIAS Eigen3_Eigen)
# eigen (header only library)
target_include_directories(${PROJECT_NAME} PUBLIC external/eigen)
# Libigl
include(libigl)
# Enable the target igl::glfw
igl_include(glfw)
target_link_libraries(${PROJECT_NAME} PUBLIC igl::glfw)
which (almost builds).
Apparently, libigl uses some depcrecated sparse matrix type in diag.cpp
(namely DynamicSparseMatrix
). Hence, i replaced in file <example project>/build/_deps/libigl-src/include/igl/diag.cpp
every DynamicSparseMatrix
with SparseMatrix
.
I assume what i did is far from optimal but for now it builds. Is the issue with DynamicSparseMatrix
knwon?
not sure about Eigen::all, would need to look into. Is it just something in a newer Eigen that we're not pulling in yet?
we've been continuing to use DynamicSparseMatrix because it was faster than SparseMatrix. Not sure if that's still the case and if it's changed from a warning to an error then I guess we'd just have to replace it on the next upgrade of Eigen.
I think its nothing newer. The Eigen::all
is at least two years out. And judging from https://github.com/libigl/libigl/blob/main/cmake/recipes/external/eigen.cmake cmake file i suppose libigl uses eigen 3.4.0 which was released about one year ago and thus definitely should come with Eigen::all
.
Regarding DynamicSparseMatrix: it seems like that it should be still supported but somehow it doesnt work with my cmake script (even though i have target_include_directories(... external/eigen)
and in libigl's diag.cpp
there is a line #include <unsupported/Eigen/SparseExtra>
which exists in external/eigen
folder). So i guess it is fine for now if you leave DynamicSparse
as part of libigl (it also seems like that workarounds with similar performance are quite ugly)
Hmm. I'm a bit confused then. When you manually include Eigen, which version are you connecting to?
It is the most recent version from the gitlab repository (downloaded via git clone)
I see. I'm ready to conclude this is an Eigen issue rather than a libigl issue. Or at least, this could be a preemptive issue for the next bump to Eigen. Preparing a PR of some necessary changes in advance could be useful but then the way I'd make the change is by bumping the version number in https://github.com/libigl/libigl/blob/main/cmake/recipes/external/eigen.cmake
The libigl-example-project is using libigl v2.4.0 by default, which pulls in Eigen 3.3.7. If you update this line to pull in the latest version of libigl (a05865e), then it will pull Eigen 3.4.0, and calling F(Eigen::all, 1)
works no problem.