0

My CMakeLists.txt file for my old libigl testing project contains the piece below:

project(libigl)

set(LIBIGL_HOME $ENV{HOME}/apps/libigl)
set(CMAKE_PREFIX_PATH ${LIBIGL_HOME})
set(CMAKE_MODULE_PATH ${LIBIGL_HOME}/cmake)
find_package(${PROJECT_NAME} CONFIGS libigl.cmake REQUIRED)

if(${PROJECT_NAME}_FOUND)
  message("-- Found ${PROJECT_NAME}")
else()
  message(FATAL_ERROR "${PROJECT_NAME} is not found")
endif()

I tried to build this project with the new version 2.4.0 of the libigl library and got this message:

CMake Error at /home/hekto/apps/libigl/cmake/libigl.cmake:5 (message):
  You included libigl.cmake directly from your own project.  This behavior is
  not supported anymore.  Please add libigl to your project via
  add_subdirectory(<path_to_libigl>).  See the libigl example project for
  more information: https://github.com/libigl/libigl-example-project/
Call Stack (most recent call first):
  CMakeLists.txt:43 (find_package)

So, they recommend to use the add_subdirectory command for client projects. I looked at the CMakeLists.txt file from the recommended GitHub example project and couldn't find the add_subdirectory command:

cmake_minimum_required(VERSION 3.16)
project(example)

list(PREPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

# Libigl
include(libigl)

# Enable the target igl::glfw
igl_include(glfw)

# Add your project files
file(GLOB SRC_FILES *.cpp)
add_executable(${PROJECT_NAME} ${SRC_FILES})
target_link_libraries(${PROJECT_NAME} PUBLIC igl::glfw)

How should I build with the new version 2.4.0 of the libigl?

  • OS: Ubuntu 20.04.5 LTS
  • Compiler: g++ (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
HEKTO
  • 3,876
  • 2
  • 24
  • 45
  • 1
    Instead of `include(libigl)` use `add_subdirectory()` as the error message suggests. You could also remove the line `list(PREPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)` - it is solely for make their `include` to work. BTW, the file [libigl.cmake](https://github.com/libigl/libigl-example-project/blob/main/cmake/libigl.cmake), included in their example, actually performs `FetchContent_MakeAvailable`, which is some sort of analogue to `add_subdirectory`. – Tsyvarev Nov 02 '22 at 22:57
  • @Tsyvarev - OK, thanks, I'll try. So, the `find_package` is not needed anymore? – HEKTO Nov 02 '22 at 23:18
  • @HEKTO: Yes, `find_package` is not needed when `add_subdirectory` approach is used. – Tsyvarev Nov 02 '22 at 23:19
  • 1
    @david-fong: The second(last) code snippet is not the code written by OP. It is `CMakeLists.txt` script in the `libigl-example-project`, which the error message refers to. Like OP, I find such example to be really confusing, as it clearly contradicts to "Please add libigl to your project via add_subdirectory()". I see nothing wrong in asking a question for clear such confusion. – Tsyvarev Nov 02 '22 at 23:25
  • @Tsyvarev - tried the `add_subdirectory`, got another error message: `add_subdirectory not given a binary directory but the given source directory "/home/hekto/apps/libigl" is not a subdirectory of "/home/hekto/EX/libigl". When specifying an out-of-tree source a binary directory must be explicitly specified` – HEKTO Nov 02 '22 at 23:32
  • 1
    @HEKTO: For use `add_subdirectory` with a directory located outside of your project you need to specify the **second argument**. See [that question](https://stackoverflow.com/questions/50408169/cmake-error-add-subdirectory-not-given-a-binary-directory) for more details. – Tsyvarev Nov 02 '22 at 23:35
  • @Tsyvarev - the `add_subdirectory` with second argument worked. However I've got other problems with the `igl_include`, but may be I'll ask a separate question. If you write an answer to this question, I'll accept it. Thank you! – HEKTO Nov 02 '22 at 23:56

0 Answers0