Your source directory might become huge if you have a lot of dependencies (and the repo size might increase dramatically as well).to fix some problem or by mistake when you refactored something). You also don’t get a clear picture if you’ve modified the dependencies’ sources (e.g.It might be hard to know which exact version the dependencies are.However, this is not the best way of doing it:
For example, you can just copy SFML sources to your /dependencies/SFML and then just do add_subdirectory(dependencies/SFML) in your main CMake file (and then link to SFML’s targets as needed)
#Cmake install executable code#
The simplest way of doing dependency management is to simply copy source code of your dependencies into your project source directory. There are a lot of ways of managing dependencies with CMake, so let’s to a quick overview of possible ways. src/Release).įor generators which don’t support multi-configuration builds in one build directory, you’ll have to make multiple build directories for each build type. If in Ninja, GNU make and so on, your example_exe will be located in /src/, in Visual Studio it will be localted in /src// (e.g.
#Cmake install executable how to#
It's better to decompose CMake build files into smaller files so that you don't get one huge `CMakeLists.txt` which builds everything, but is several thousands lines long and hard to maintain.įor example, if you have an examples directory, it's good to have a examples/CMakeLists.txt which will just be a bunch of add_subdirectory calls for each sub-directory and example/some_example/CMakeLists.txt will be a build script which contains information on how to build some_example.Ĭmake -build. It’s actually a bit more complex, but it’s okay to think about it as “include” at the beginning. I’ve seen a lot of people getting VERSION from a current Git tag or some changelog file, but we’ll not go here in this tutorial.Īdd_subdirectory() is like an “include” and can be thought of as an inclusion of /CMakeLists.txt into another CMake file. It can be used to generate “version” headers (here’s an example of how to do it), write some output in a terminal and so on. VERSION option specifies a current version of your project. If you’re doing C or C++ project, it’s optional to specify it, but it’s still useful as a “meta-data” for people who’re reading your CMake build. By default it’s C and CXX, but there are a lot of other options available for you (like CUDA or Fortran). LANGUAGES option in a project call defines a language which your project uses so that CMake knows what kind of builds to generate. You don't need to make a new project for each of these targets - in most cases one project is enough. it can run unit tests, linters and so on).įor example, if you're making a game, you can have multiple targets - a game's main executable, the engine's library (which can be a static or a shared library), a level editor executable and so on. The target can be an executable, a library or even something which doesn’t produce any files after it’s built (e.g. One project can have multiple “targets” (which roughly correspond to “projects” in VS). The project is similar to a concept of “solution” in Visual Studio terminology.
I’ll try to explain everything as I go on down to a “basic” things. You won’t need to use prebuilt libraries ever again. The project will clone these dependencies’ source code from Github and build them. We’ll go step by step and create a simple project which will have SFML, Dear ImGui and ImGui-SFML as its dependencies. CMake’s FetchContent makes it much more manageable and easy to do. Building C++ projects and managing dependencies is hard.
0 kommentar(er)
