CMake error building with Python libraries

Problem

I got this error from CMake when building a project that needs to link with Python 3.4 libraries:

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.3", minimum required is "3.0")
-- Could NOT find PythonLibs (missing:  PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS) (Required is at least version "3.0")

Solution

Turns out that the CMake available on my system only supported finding Python 3 packages upto version 3.3. To change it to support Python 3.4 was possible by editing two files:

  • In file /usr/share/cmake-3.4/Modules/FindPythonInterp.cmake find the line containing _PYTHON3_VERSIONS and prepend 3.4 to the versions already listed there.

  • In file /usr/share/cmake-3.4/Modules/FindPythonLibs.cmake find the line containing _PYTHON3_VERSIONS and prepend 3.4 to the versions already listed there.

I was able to build with Python 3.x libraries after that.

Advertisements

How to import CMake project in Qt Creator

Importing a CMake project into Qt Creator is easier than it is with Eclipse (which is described here). The problem is that you cannot do this properly by using the Import option. Counter-intuitively, you need to Open Project to import a CMake project and make a Qt Creator project from it. After this operation, the project will be available in Qt Creator always, with auto-complete (thanks to indexing) and building (thanks to make).

To do this:

  • Do Open file or project and open the CMakeLists.txt file.
  • Choose the Build directory properly. Qt Creator will create a .cbp file here with the name of the CMake project.
  • Qt Creator will ask you to run cmake once, so that it can learn the include, library and build directories.
  • You are now in the project Qt Creator has created for you. It will index the files perfectly, so you get excellent auto-complete (better than Eclipse).
  • Click the Projects button in left column and you will be able to set the command options to build and the environment variables for build.

Tried with: Qt Creator 3.5.0 and Ubuntu 14.04

CMake error on Qt5Core

Problem

I tried to build source code that uses Qt5 using CMake. It quit with this error:

CMake Error at CMakeLists.txt:20 (find_package):
  By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5Core", but
  CMake did not find one.

  Could not find a package configuration file provided by "Qt5Core" with any
  of the following names:

    Qt5CoreConfig.cmake
    qt5core-config.cmake

  Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set
  "Qt5Core_DIR" to a directory containing one of the above files.  If
  "Qt5Core" provides a separate development package or SDK, be sure it has
  been installed.

Solution

I checked for Qt5 packages and they seemed to be installed. There has been a naming change between Qt4 and Qt5 packages in Ubuntu and that threw me off.

What was needed is the package qtbase5-dev. Once I installed it, this error was solved:

$ sudo apt install qtbase5-dev

Tried with: Ubuntu 14.04

How to build and use GLFW

GLFW is a library for OpenGL created by Camilla Berglund. It is a modern replacement to GLUT, to draw windows and handle input.

GLFW 2.x

Ubuntu ships with an ancient version of GLFW that can be installed easily:

$ sudo apt install libglfw-dev

However, it is highly recommended to use GLFW 3.x. It has a different API and your source code and build options will need to be changed to use it.

To remove this ancient GLFW:

$ sudo apt remove libglfw-dev glfw2

GLFW 3.x

I like to install GLFW from Github. You could also get one of its stable releases, the installation steps would be the same for either.

  • Get the source:
$ git clone https://github.com/glfw/glfw.git
  • Build the library. Note that we request CMake to create shared library files. Why this is not the default on Linux puzzles me!
$ cd glfw
$ mkdir build
$ cd build
$ cmake -D BUILD_SHARED_LIBS=ON ..
  • Install the library:
$ sudo make install

Note that I highly recommend using checkinstall as described here instead of doing this.

  • Update the dynamic linker cache, so that the libglfw.so shared library file can be loaded at runtime:
$ sudo ldconfig

If you do not do this, you get an error similar to that described here.

  • To use GLFW 3.x calls in your code, include the header file:
#include <GLFW/glfw3.h>
  • To link and build your code use the library directive: -lglfw to your build options or CMake.

Tried with: GLFW 20150825 and Ubuntu 14.04

How to set link directories in CMake

For most common libraries, CMake has inbuilt modules which find and include them for compilation and linking. But, there are situations where you need to use library files (say *.so) that are in a custom directory somewhere that need to be linked with the code you are building.

One or more of such paths which should be requested to search for library files while linking can be specified like this:

link_directories(
    /home/joe/bellringer/lib64
    /home/joe/globespin/libs
)

The library files in these directories can now be specified in link_libraries or target_link_libraries using the usual -l syntax.

Reference: link_directories

Tried with: CMake 2.8.12.2 and Ubuntu 14.04

How to use shell environment variables in CMake

Many developer SDKs and libraries set their own environment variables. For example, installing OpenNI2 sets OPENNI2_INCLUDE to the path containing its header files. It would be convenient to use these shell environment variables directly in CMake without having to create another CMake variable for it.

This can be done in CMake easily. For example to set the above environment variable as an include directory:

include_directories(
    /home/joe/globespin/include
    $ENV{OPENNI2_INCLUDE}
)

Tried with: CMake 2.8.12.2 and Ubuntu 14.04

Build types in CMake

A build type indicates a set of compile-time decisions used while compiling your code. For example, whether or not to optimize or to include debug information. A build type or build mode or configuration is popular in Visual Studio, where C++ projects typically have at least two types: Release and Debug.

CMake has build types and follows similar rules. For compiling C++, there are at least 4 build types in CMake: Release, Debug, MinSizeRel and RelWithDebInfo.

  • The compile options or rules associated with a build type for a source file of a particular language can be found in /usr/share/cmake-2.8/Modules/Find*.cmake. For compiled languages like C++, look for the matching compiler in /usr/share/cmake-2.8/Modules/Compiler directory.

  • For C++ code compiled using GNU C++ compiler, see the files /usr/share/cmake-2.8/Modules/Compiler/GNU.cmake for the options used during compilation.

  • When no build type is provided, I found the compilation string to be: g++ /your/code.cpp

  • For Release build type, I found the compilation string to be: g++ -O3 -DNDEBUG /your/code.cpp. Note that assert will be disabled with this build type.

  • For Debug build type, I found the compilation string to be: g++ -g /your/code.cpp

  • You can specify a build type in the CMakeLists.txt file. For example:

set(CMAKE_BUILD_TYPE Release)
  • You can also specify a build type at the shell. For example:
$ cmake -D CMAKE_BUILD_TYPE=Debug ..
  • You can make one of the build types as default, when no build type is provided. For example, to make Release build type as default, add this to CMakeLists.txt:
if(NOT CMAKE_BUILD_TYPE) 
    set(CMAKE_BUILD_TYPE Release)
endif(NOT CMAKE_BUILD_TYPE)

Note: Build types for Visual Studio cannot be set in CMakeLists.txt using CMAKE_BUILD_TYPE or any other method. It can only be set when CMake is invoked or later in the Visual Studio solution.

Tried with: CMake 2.8.12.2 and Ubuntu 14.04

CMake fails looking for CUDA_TOOLKIT_ROOT_DIR

Problem

You have installed CUDA and try to compile a CUDA program using a CMake, which fails with this error:

$ cmake ..
CMake Error at /usr/share/cmake-2.8/Modules/FindCUDA.cmake:548 (message):
  Specify CUDA_TOOLKIT_ROOT_DIR
Call Stack (most recent call first):
  CMakeLists.txt:3 (find_package)

Solution 1

FindCUDA.cmake is trying to find your CUDA installation directory and failing. I had installed CUDA 7.0 on this machine, which was in /usr/local/cuda-7.0. However, CMake looks for /usr/local/cuda. The CUDA installer is supposed to create a symbolic link /usr/local/cuda pointing to that actual installation directory.

That symbolic link was not there on this computer. This can sometimes happen when you have two CUDA installations and remove one of them. The one removed takes out the symbolic link with it. I had CUDA 6.5 and CUDA 7.0 on this computer before I removed CUDA 6.5.

Anyway, we now know how to fix this:

$ sudo ln -s /usr/local/cuda-7.0 /usr/local/cuda

Solution 2

Pass the CUDA installation directory to the CUDA_TOOLKIT_ROOT_DIR variable directly during the invocation of CMake:

$ cmake -D CUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda-7.0 ..

Tried with: CUDA 7.0 and Ubuntu 14.04

target_include_directories does not work with CUDA

Problem

target_include_directories is an useful CMake directive to specify the include directories for building a particular target, as described here. The FindCUDA module for CMake which handles CUDA compilation seems to completely ignore this directive. The include directories specified for the target are not passed to CUDA compilation by nvcc.

This will most commonly result in errors of the form: someheader.h: No such file or directory.

Solution

This is a well known limitation of the CUDA module of CMake, as documented here. There seems to be no plan currently to support target_include_directories for CUDA compilation.

The only solution is to switch to include_directories to add these directories for all the targets in the CMakeLists.txt file.

Tried with: CMake 2.8.12.2, CUDA 6.5 and Ubuntu 14.04

How to use Quickfix feature of Vim for compilation

Compile, view errors and fix them from inside Vim using Quickfix
Compile, view errors and fix them from inside Vim using Quickfix

The Quickfix feature of Vim is great if you work regularly with source code of languages which need to be compiled, like C or C++. If you are coming from Visual Studio or Eclipse CDT, the Quickfix feature basically gives an IDE-like feel of the edit-compile-fix cycle. (The only missing piece is a visual debugger inside Vim.) For example, you can view the errors and warnings produced on compiling your code in the Quickfix window, jump to the location of the error or warning, fix them and compile the code again. All from within Vim! 🙂

Here are some pointers on how I use Quickfix:

  • Quickfix is a plugin that ships with Vim. So, there is nothing to install!

  • If you have a compile command, then redirect its output to a file. Use the -q option of Vim to open this file and you can navigate the errors from there (as described later below). For example:

$ g++ main.cpp 2> errors.txt
$ vim -q errors.txt
  • If you are using CMake or Make, then life is much easier for you. Open Vim in build directory and invoke make from within it using the command :make. This runs Make and fills up the Quickfix buffer with the error output.

  • To open the Quickfix window, use the command :copen. In the screenshot above, the Quickfix window is visible at the bottom.

  • Navigate the Quickfix window as usual and press Enter on any error or warning line. That file, which may not even be in the same directory, is opened in the top window and the cursor is placed at the line and column of the error. Now, is that not like an IDE! 🙂

  • Now you can jump between the editor window and Quickfix window, using the usual Ctrl + w + w command and fix all the errors.

  • Once done, you can compile again right from inside Vim using :make. More errors? Fix them. And the edit-compile-edit cycle continues 🙂

  • For more help on Quickfix, see :help quickfix

Tried with: Vim 7.4 and Ubuntu 14.04