I have been attempting to build a simple C++ library. Along the course of building by using relative paths CMake could not properly configure where my link library in located. With absolute path configuration was successful. This has been among some of the things that put me off from using CMake. What is the recommended way of setting up paths? Is it absolute or relative paths and why?
2
- Why not go with using path stored within environment variables?Aziuth– Aziuth2017-07-13 14:38:20 +00:00Commented Jul 13, 2017 at 14:38
- CMake uses mostly absolute paths. But since everything can be defined relative to CMake system variables, which can also be user customized, and subdirectories inherit parent variables, this is no limitation at all for either developers or users. Just post a minimal but complete version of your code and you can get more useful help.utopia– utopia2017-07-13 15:19:07 +00:00Commented Jul 13, 2017 at 15:19
Add a comment |
1 Answer
given: cmake -H/foo -B/bar
during execution of /foo/CMakeLists.txt:
${CMAKE_CURRENT_SOURCE_DIR} = /foo ${CMAKE_CURRENT_BINARY_DIR} = /bar after the statement project(Foo)
${PROJECT_SOURCE_DIR} = /foo ${PROJECT_BINARY_DIR} = /bar then during statement add_subdirectory(foo2), i.e. executing /foo/foo2/CMakeLists.txt:
${CMAKE_CURRENT_SOURCE_DIR} = /foo/foo2 ${CMAKE_CURRENT_BINARY_DIR} = /bar/foo2 ${PROJECT_SOURCE_DIR} = /foo ${PROJECT_BINARY_DIR} = /bar if we encounter another nested project: project(Bar)
${CMAKE_CURRENT_SOURCE_DIR} = /foo/foo2 ${CMAKE_CURRENT_BINARY_DIR} = /bar/foo2 ${PROJECT_SOURCE_DIR} = /foo/foo2 ${PROJECT_BINARY_DIR} = /bar/foo2 There are many other variables that will help you to locate and position files accurately, see
https://cmake.org/Wiki/CMake_Useful_Variables
commands such as add_executable will try to "figure out" where non-explicit files are, but in complicated projects it's not a good idea to rely on it. Better to offer paths explicitly (using the CMAKE variables available).
In the end, if you use cmake regularly, you will come to the conclusion that source file organisation is its weak point.
If you're lucky like me, you'll stumble across the Sugar package:
https://github.com/ruslo/sugar
And all your source file (and documentation) woes will vanish.
If you cross-compile, you'll want Polly:
https://github.com/ruslo/polly
And if you rely on common 3rd party libraries you may well benefit from Hunter:
