In
https://github.com/abedra/libvault/blob/5703ef4c171ee559669e97330ab86212b4cff3e4/CMakeLists.txt#L159
CMAKE_BINARY_DIR is used for marking the source file for install. This causes an error when libvault is built using a CMakeLists.txt wrapper like the following:
message(INFO This is a CMake Wrapper allowing to set up custom CMake options similar to -D command line arguments) add_subdirectory(libvault)
As add_subdirectory CMake function creates a new directory in the build tree that will make CMAKE_BINARY_DIR different to CMAKE_CURRENT_BINARY_DIR, installation will fail not being able to locate ${PROJECT_NAME}.pc
A trivial solution is to change the following line
https://github.com/abedra/libvault/blob/5703ef4c171ee559669e97330ab86212b4cff3e4/CMakeLists.txt#L159
to
install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.pc"
Apart from fixing this niche bug, this will make that line consistent with the rest of the CMakeLists.txt where
${CMAKE_CURRENT_BINARY_DIR} is used.
In https://github.com/abedra/libvault/blob/5703ef4c171ee559669e97330ab86212b4cff3e4/CMakeLists.txt#L159 CMAKE_BINARY_DIR is used for marking the source file for install. This causes an error when libvault is built using a CMakeLists.txt wrapper like the following:
message(INFO This is a CMake Wrapper allowing to set up custom CMake options similar to -D command line arguments) add_subdirectory(libvault)
As add_subdirectory CMake function creates a new directory in the build tree that will make CMAKE_BINARY_DIR different to CMAKE_CURRENT_BINARY_DIR, installation will fail not being able to locate ${PROJECT_NAME}.pc A trivial solution is to change the following line https://github.com/abedra/libvault/blob/5703ef4c171ee559669e97330ab86212b4cff3e4/CMakeLists.txt#L159 toinstall(FILES "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.pc"
Apart from fixing this niche bug, this will make that line consistent with the rest of the CMakeLists.txt where ${CMAKE_CURRENT_BINARY_DIR} is used.