Am trying to change default storage of the library, executable and include files to a specified directory in Cmake.
For e.g.: When I run Cmake, it will get build in a particular directory (where the source files are kept) and also generates the executables, libraries and include files in the same source directory. I want to define the output path for executables, libraries and include files in below structure.
X:\Builddirectory\lib\Debug\.... library files.
X:\Builddirectory\lib\Release\.... library files.
X:\Builddirectory\include\.... all the include files.
X:\Builddirectory\bin\.... executable files.
In order to perform the above, following CMake variables needs to be set.
But I am not aware how to edit these variables:
LIBRARY_OUTPUT_PATH
EXECUTABLE_OUTPUT_PATH
PROJECT_BINARY_DIR
may be some other variables as well.
Thanks for suggestions and help.
Once you open the CMAKE gui, Check for the above mentioned cmake variables, if they are not defined or defined with default path Consider performing the below mentioned.
1. If defined with default path then change it to the desired PATH
2. If the variable is not defined/assigned or could you not find in the CMAKE list then consider adding the variable by using "ADD Entry" option in the Gui.
Related
I am building a project from source and am trying to understand what is happening in the CMakeLists.txt files.
Where exactly is target_link_libraries looking for the required library files?
The specific CMakeLists.txt file I have has:
target_link_libraries(MyApplication PRIVATE
Magnum::Application
Magnum::GL
Magnum::Magnum
Magnum::Shaders)
I found folders that have the names GL and Shaders in a directory called Magnum in the project, and they have a collection of header files in them. I believed that target_link_libraries is telling CMake to include the libraries in the GL and Shaders folder.
However, I cannot seem to find a corresponding folder for Application, hence my line of reasoning must be flawed.
I do know target_link_libraries is doing something related to allowing the finally-put-together program to be able to use a set of libraries.
What exactly does target_link_libraries do? Where does it look for the required files in order to be able to use the libraries it needs to?
target_link_libraries doesn't link anything automatically. You should have a target previously created via add_library (or add_executable), where all files are listed.
The way these targets added into your CMake project may differ. E.g. you may have a library source files with CMakeLists.txt configuration (where the said add_library command is) under some folder libs/mylib. Then in your CMakeLists.txt you may have the library added with add_subdirectory(libs/mylib). Another option is to add the library with find_package.
In your specific case, you pass targets to target_link_libraries(). Targets with a shape like Magnum::Application etc are either imported targets or ALIAS targets.
From what you say, it seems than Magnum is vendored into your project, so I guess your are linking ALIAS targets, like the one defined here https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb61f70b2e61eb9ce8d/src/Magnum/CMakeLists.txt#L295
Targets defined by add_library() or add_executable() in CMake are an abstraction carrying several informations, including location of files.
I have a C++ project that needs to be built with CMake and MinGW-W64.
Some libraries (such as zlib, libpng) are in: C:\Dev\mingw64-5.3.0\x86_64-w64-mingw32\
So I use : -DCMAKE_PREFIX_PATH="C:\Dev\mingw64-5.3.0\x86_64-w64-mingw32"
But, I get a compilation error because the following header is outdated and miss important symbols:
C:\Dev\mingw64-5.3.0\x86_64-w64-mingw32\include\float.h
If I add a compiler flag to search into the proper include directory for float.h:
-DCMAKE_CXX_FLAGS="-isystem C:/Dev/mingw64-5.3.0/lib/gcc/x86_64-w64-mingw32/5.3.0/include"
Then, this does not work, since CMake will add this folder after its generated includes_CXX.rsp
How can I handle this issue? Is there a way to enforce header search path priority?
You could also add the include location(s) to environment variable C_INCLUDE_PATH and CPLUS_INCLUDE_PATH.
To locate the libraries you can do the same for the lib with the LIBRARY_PATH environment variable.
For DLL and EXE files you may even need to add the bin path to PATH.
Usually, open source packages will have cmake to check if some headers or libraries exists or not, I wish my own project has this same functionality.
So I wish to know if cmake provides some command to check if some ".so"/".a"/".h" files exists in the current linux system or not, if not cmake will give me some hint to install them?
How does cmake support this?
Usually one would use the find_package(ABC REQUIRED) and then refer to it in your project. This will ensure that the dependent library is installed and cmake will fail if it is not.
You can find lot's of example on how this works in your cmake installation, for example C:\Program Files\CMake\share\cmake-3.13\Modules\FindZLIB.cmake will search for the zlib library by looking in the file system for normal places where this library would be installed and if it finds it will set these variables accordingly:
# ZLIB_INCLUDE_DIRS - where to find zlib.h, etc.
# ZLIB_LIBRARIES - List of libraries when using zlib.
# ZLIB_FOUND - True if zlib found.
To achieve this header files are found using the cmake command find_path, and libraries (static and shared) are found using find_library.
To search for arbitrary library you can use find_library() command. Same task for headers is accomplished by find_file(). You can also search for executables with find_program().
As #Damian said in his naswer, many libraries provide "config" files, like FindBoost.cmake. Such libraries can be found by calling find_package(Boost) command. This command would locate and load config file and set corresponding variables.
You need to provide -config.cmake files to tell other projects where your libraries and headers are. Here, you will found what are you looking for.
I've added the yaml-cpp git repository as a submodule and add it to my CMake project using add_subdirectory.
Everything's fine but I have to set YAML_CPP_INCLUDE_DIR and YAML_CPP_LIBRARIES manually to use them for my own targets.
Because there is a file yaml-cpp-config.cmake (generated in the build folder) setting these variables I tried to just include it:
include("${CMAKE_BINARY_DIR}/yaml-cpp/yaml-cpp-config.cmake")
but then I get:
CMake Error at /bla/bla/build/yaml-cpp/yaml-cpp-config.cmake:11 (include):
The file
/bla/bla/aml-cpp/yaml-cpp-targets.cmake
was generated by the export() command. It may not be used as the argument
to the include() command. Use ALIAS targets instead to refer to targets by
alternative names.
I really don't understand this message. How would I provide my targets with the yaml-cpp include directories and libraries without having to set a hard coded variable?
I'm not searching for a way to correctly include() the file in case it doesn't have to be done. I'm just interested in how I should provide the desired information to my targets.
Unfortunately yaml-cpp seems to not make use of target_include_directories() which would set the include directories automatically where needed.
From description of export command:
Create a file <filename> that may be included by outside projects to import targets from the current project’s build tree.
Note to "outside" word: this is why you get the error message while trying to include the file from the same project, which issues export command.
Correct way to use yaml-cpp-config.cmake file would be building yaml-cpp outside of your project. For example, you may use ExternalProject_Add in conjunction with execute_process for build yaml-cpp as part of configuration stage of your project, see more about this approach here.
Then you may include given file to your project with find_package:
find_package(yaml-cpp PATHS <yaml-cpp-build-dir>)
Note, that yaml-cpp-config.cmake in binary directory describes build state of yaml-cpp project.
If you want to install libraries/executables from your project, you are better to install yaml-cpp, and include corresponded file from its installation directory:
find_package(yaml-cpp PATHS <yaml-cpp-install-dir>)
I am writing a C++ library (header-only) and am using CMake to generate my (Visual Studio) project and solution files. I'm also writing a test suite, which is part of the same CMake project.
My problem occurs when I call target_include_directories() on the target that represents my header-only library, so that consumers of my library may find its header files. I get the following error message (even though generation is NOT aborted).
CMake Error in CMakeLists.txt:
Target "Fonts" INTERFACE_INCLUDE_DIRECTORIES property contains path:
"D:/Projects/GPC/fonts/include"
which is prefixed in the source directory.
(D:/Projects/GPC/Fonts being the top-level directory of my library project. Btw the problem remains if I move my header files to the top directory.)
The offending line in my CMakeLists.txt is this (adapted for simplicity):
target_include_directories(Fonts INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}/include")
I do not understand what I'm doing wrong. Without target_include_directories(), code of consumer projects simply can't include my header files (unless in installed form, but I haven't gotten to that yet, and in any case I want to be able to use my library from its build tree, without installation.)
I feel like I'm missing something basic here; yet I've searched for hours without finding a solution or explanation.
The origin of the problem is not the target_include_directories command itself, but the attempt to install a target that has a public or interface include directory prefixed in the source path (i.e. the include directory is a subdirectory of your ${PROJECT_SOURCE_DIR}.)
While it is perfectly fine and desirable to use absolute paths when building the library from scratch, a third party library that pulls in a prebuilt version of that library will probably want to use a different include path. After all, you do not want all of your users to mirror the directory structure of your build machine, just to end up in the right include path.
CMake's packaging mechanism provides support for both of these use cases: You may pull in a library directly from the build tree (that is, check out the source, build it, and point find_package() to the directory), or from an install directory (run make INSTALL to copy built stuff to the install directory and point find_package() to that directory). The latter approach needs to be relocatable (that is, I build and install on my machine, send you the resulting directory and you will be able to use it on your machine from a different directory structure), while the former is not.
This is a very neat feature, but you have to account for it when setting up the include directories. Quoting the manual for target_include_directories:
Include directories usage requirements commonly differ between the
build-tree and the install-tree. The BUILD_INTERFACE and
INSTALL_INTERFACE generator expressions can be used to describe
separate usage requirements based on the usage location. Relative
paths are allowed within the INSTALL_INTERFACE expression and are
interpreted relative to the installation prefix. For example:
target_include_directories(mylib PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include/mylib>
$<INSTALL_INTERFACE:include/mylib> # <prefix>/include/mylib
)
The BUILD_INTERFACE and INSTALL_INTERFACE generator expressions do all the magic:
$<INSTALL_INTERFACE:...>
Content of ... when the property is exported using install(EXPORT), and empty otherwise.
$<BUILD_INTERFACE:...>
Content of ... when the property is exported using export(), or when the target is used by another target in the same buildsystem.
Expands to the empty string otherwise.