7

I am learning CMake and I am having problems in understanding its multi-step workflow. So far, my understanding is that you:

  • write a CMakeLists.txt
  • run cmake from a subdirectory to generate a build file (a Makefile, in my case)
  • run make

However, I don't understand how you should handle different targets (Release vs Debug). By running CMake in two different subdirectories?

Also, I don't understand why you would edit CMakeCache.txt (there is also a GUI tool for that). To emulate what you would accomplish with ./configure by passing different options?

Eleno
  • 2,864
  • 3
  • 33
  • 39

2 Answers2

9

You got it pretty much right. The write CMakeLists.txt > cmake > make sequence is correct.

Regarding different configurations (Debug vs. Release), you have to differentiate between multi-config generators (Visual Studio, XCode), and single-config generators (everything else). With the multi-config generators, you generate one buildsystem (e.g. solution file) which contains all configurations, and choosing between them happens at build time.

With single-config generators, different configurations are obtained by generating different buildsystems, that is, by running CMake multiple times in different directories (and with a different value of the CMAKE_BUILD_TYPE CMake variable).

So you'd do something like this:

> cd my_project/bld/debug
> cmake ../../src -DCMAKE_BUILD_TYPE=Debug
> cd ../release
> cmake ../../src -DCMAKE_BUILD_TYPE=Release

Regarding editing the cache (usually through CMake GUI or ccmake): you're right again, this largely corresponds to passing options to ./configure from AutoMake world. This would be the typical workflow with a freshly downloaded project (using CMake GUI):

  1. Run CMake GUI, point it to the source directory (input) and binary directory (output) you want
  2. Configure. This will fill the cache with project-specified defaults. If CMake cannot find some dependencies of the project automatically, this will end with an error.
  3. Inspect the cache, change any values you don't like (such as compilation options), fill in any missing options (paths to libraries CMake couldn't find etc.)
  4. Repeat steps 2 & 3 until you're satisfied with the project's setup.
  5. Generate the buildsystem.
  6. Exit CMake GUI and build using the appropriate build tool.
Angew is no longer proud of SO
  • 167,307
  • 17
  • 350
  • 455
  • 1
    you can of course pass the options to the cmake configuration step instead of setting them in cmake-gui: `cmake ... -DWITH_SQLITE=ON ...` – tamas.kenez Jul 06 '15 at 08:35
  • You can use the same build directory for Debug and Release configs if your build system can be trusted not to accept Debug object files for the Release build and regenerate them. Otherwise you can build with `cmake --build ... --clean-first` – tamas.kenez Jul 06 '15 at 08:38
  • @tamas.kenez I don't think you can reliably use the same binary dir for multiple configurations. CMakeLists can contain `if(CMAKE_BUILD_TYPE ...)`-style code, meaning only the last configuration for which you ran `cmake` would be the one you could reasonably build. – Angew is no longer proud of SO Jul 07 '15 at 07:21
  • @Angew, yes, of course, that's what I meant, always configure first and build right after it. As a sidenote, when people are using multiconfig-generators (Xcode & VS) the way they used to it, that is, not specifying `CMAKE_BUILD_TYPE` for the cmake-config step, `if(CMAKE_BUILD_TYPE)`-like constructs will fail. So that should be avoided. – tamas.kenez Jul 07 '15 at 21:36
1

What @Angew said. Plus here's an image of the cmake-gui:

Also note that you install it (the CMake GUI) on Ubuntu with sudo apt install cmake-qt-gui, and you run it with cmake-gui.

Source: Where is the CMake GUI for Linux?

Here's my cmake-gui image:

enter image description here

Gabriel Staples
  • 36,492
  • 15
  • 194
  • 265