Working with an existing nested cmake project

Answered

I have a sizeable existing cmakefile project with nested cmakelists.txt files in every directory of a large tree. How do I open this with CLION to recognize all the targets throughout the tree so I can build/debug them? Right now I open the root cmakelists.txt file and it doesn't show any targets (and therefore there is no configuration) since there are no targets defined at the project root. I have made several of my own projects with CLION and it has been really great to work with but I have been banging my head against the wall on working with this existing project.

2
5 comments

Hello!

Does your root cmakelists.txt  contain add_subdirectory() projects pointing to the actual projects? In this case CLion should see the targets defined in the subprojects.

Also feel free to comment or upvote https://youtrack.jetbrains.com/issue/CPP-1537.

1
Avatar
Permanently deleted user

I can build the project using cmake at the command prompt. I normally create a build artifacts directory below the project root and simply enter "cmake ..\". It builds a number of libraries and binaries. The executables are built due to CMakeLists.txt files several levels into the directory structure (under subdirectory blah-core you can see referenced at the bottom of the top-level CMakeLists.txt file). I have tried opening that CMakeFiles.txt file and it doesn't show any configurations and won't build either. Do I have to manually add configurations or something? I thought it would just traverse the tree (thanks to subdirectory lines in the CMakeLists.txt files) and build from the top-level CMakeLists.txt. Are the targets limited to one level of subdirectory or is CLION supposed to crawl the whole tree?

This is my top-level CMakeFiles.txt with the names of my directory structure obfuscated...

 

make_minimum_required(VERSION 3.5.1)

project(blah LANGUAGES CXX)

# Set default pref to /usr (unless user provided an override)
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
set(CMAKE_INSTALL_PREFIX "/usr" CACHE PATH "..." FORCE)
endif()

set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

if(${CMAKE_VERSION} VERSION_LESS "3.12.1")
message("Please consider switching to CMake 3.12.x")
else()
# Enable PACKAGE_ROOT variable for find_package()
cmake_policy(SET CMP0074 NEW)
endif()

set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O2" )

find_package(Boost COMPONENTS program_options REQUIRED)

enable_testing()

set(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/artifacts CACHE STRING "Choose the installation prefix." FORCE)

# Setup GTest
find_package(GTest)
if(NOT TARGET gtest_main)
# FIXME: Make this friendlier to the cross-build
add_subdirectory(/usr/src/googletest gtest)
endif()

set(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/artifacts CACHE STRING "Choose the installation prefix." FORCE)

add_subdirectory(dir1)
add_subdirectory(dir2)
add_subdirectory(blah-core)

0

If there is a top-level CMake file containing add_subdirectory() projects, CLion should create targets defined in the subprojects.

For example, here is our demo project with a similar structure - https://github.com/anastasiak2512/Calendar. If I open the project in CLion, it creates the configurations for targets defined in the subprojects:

Could you please check whether CLion creates the configurations for this demo project on your side?

1

I'm facing the same problems. CMake won't detect targets for subdirectories nested in existing subdirectories. For example, if the root CMakeLists uses add_subdirectory(calendars), and the CMakeLists uses add_subdirectory(mysubproject), CMake doesn't crawl the subdirectory tree, and won't recognise the targets from /calendars/mysubproject/CMakeLists.txt

0

pygrum, in the sample project mentioned earlier (https://github.com/anastasiak2512/Calendar):

  • the top-level Calendar/CMakeLists.txt file has add_subdirectory(calendars_tests)
  • the Calendar/calendars_tests/CMakeLists.txt file has add_subdirectory(basic_tests)
  • and the Calendar/calendars_tests/basic_tests/CMakeLists.txt file defines the target “runBasicCalendarTests”. 

The “runBasicCalendarTests” target is correctly detected by CLion and the corresponding configuration is automatically created on my side:

Do you observe different behavior if you open https://github.com/anastasiak2512/Calendar in CLion on your side?

0

Please sign in to leave a comment.