0

I have a project with the following layout:

.
|_include
| |_GLFW
|   |_glfw3.h
|_lib
| |_glfw3.lib
|_src
| |_main.cpp
|_build
|_CMakeLists.txt

The CMakeLists.txt looks like this:

cmake_minimum_required( VERSION 3.14 )

project( example LANGUAGES CXX )

set( INCLUDE_HEADERS
   include/GLFW/glfw3.h
)

set( SRC
    src/main.cpp
)

source_group( include FILES ${INCLUDE_HEADERS} )
source_group( src FILES ${SRC} )

add_executable( example ${INCLUDE_HEADERS} ${SRC} )

target_link_libraries( example "${CMAKE_BINARY_DIR}/lib/glfw3.lib" )

I go to ./build and type cmake ..

This creates a Visual Studio 2017 solution as expected. But in the example project, it lists the dependency path of glfw3.lib as lib\glfw3.lib and says it can't find it.

As far as I understand, CMAKE_BINARY_DIR is supposed to represent the absolute path of the project, and that is what I get if I try to print it out using message. Why does it change the absolute path to a (faulty) relative path in the Visual Studio solution?

I have also tried using CMAKE_SOURCE_DIR, CMAKE_CURRENT_BINARY_DIR and CMAKE_CURRENT_SOURCE_DIR, and all of them change the absolute path to a relative path.

linkalonk
  • 1
  • 1
  • Please, show (add to the question post) the **exact error message** you got. BTW, `CMAKE_BINARY_DIR` points to the `_build` directory in your project's layout. Path to the lib file should be `${CMAKE_SOURCE_DIR}/lib/glfw3.lib` or `${CMAKE_CURRENT_SOURCE_DIR}/lib/glfw3.lib`. – Tsyvarev Jun 05 '19 at 10:35
  • @Tsyvarev I'm less interested in why the Visual Studio project fails, and more about why CMake has this behavior, since I can't find anything in the documentation on `target_link_libraries` to explain it. `CMAKE_SOURCE_DIR` was what I originally used, but `CMAKE_BINARY_DIR` is what's in my latest attempt. I tried four in total, listed in the last paragraph, and all printed the absolute path when using `message` in the CMake script, but became a relative path in the Visual Studio project. – linkalonk Jun 05 '19 at 10:42
  • I know that CMake sometimes shortens absolute path to the library to the path relative to the current binary directory. Or leaves only the library name in case it finds the directory to be already searched by the linker. But `CMAKE_SOURCE_DIR` falls to none of these categories... Are you sure that you check exactly that project, which is generated by CMake using the `CMakeLists.txt` you show? What if you use, e.g. `/a/b/c/d/` (literally) as this directory? – Tsyvarev Jun 05 '19 at 11:50
  • @Tsyvarev Yes, it is definitely the same project. Changes in the CMakeLists.txt are reflected in the project I am checking. I tried hardcoding the full path to the lib just now, and it also shortens it down to a relative path. But are you saying that this is expected behavior? If so, is there an alternative to `target_link_libraries` that retains the absolute path? – linkalonk Jun 05 '19 at 13:34
  • "But are you saying that this is expected behavior?" - In some cases reducing the path is expected behavior. But I am not sure where your case is one of those cases. "If so, is there an alternative to `target_link_libraries` that retains the absolute path?" - Linking with IMPORTED target should always retain absolute path. See [that answer](https://stackoverflow.com/a/10550334/3440745) about such linking. – Tsyvarev Jun 05 '19 at 14:41
  • @Tsyvarev Oh, that may be exactly what I'm looking for then. Thank you very much! – linkalonk Jun 05 '19 at 21:03

0 Answers0