Eigen::all Eigen::placeholders::all Eigen::indexing::all not available in example project

[paul0noah]

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!

[paul0noah]

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?

[alecjacobson]

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.

[paul0noah]

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)

[alecjacobson]

Hmm. I'm a bit confused then. When you manually include Eigen, which version are you connecting to?

[paul0noah]

It is the most recent version from the gitlab repository (downloaded via git clone)

[alecjacobson]

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

[jdumas]

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.

[paul0noah]

Thanks @jdumas this works! Apparently, this is also mentioned in release log of libigl v2.4.0 (see here). Maybe it makes sense to mention it somwhere in the example project how to pull in newest version of libigl?

[alecjacobson]

Ah. Nice catch. I wonder if the example project should have similarly tagged releases and then the main branch can be loosely up to date

On Wed, Apr 12, 2023, 5:32 AM paul0noah @.***> wrote:

Thanks @jdumas https://github.com/jdumas this works! Apparently, this is also mentioned in release log of libigl v2.4.0 (see here https://github.com/libigl/libigl/releases). Maybe it makes sense to mention it somwhere in the example project how to pull in newest version of libigl?

— Reply to this email directly, view it on GitHub https://github.com/libigl/libigl-example-project/issues/38#issuecomment-1504961427, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARDJGOZ6DT3UGBEUVXQ7UTXAZZCNANCNFSM6AAAAAAW2BR5XU . You are receiving this because you commented.Message ID: @.***>