Introducing cmake_install

Merry Christmas everyone,

Holidays have come and I’ve finally got some time to get back to KDE for as long as the holidays last. Today I started from updating my KDE-trunk installation and while building, I remembered about this handy cmake_install utility that I wrote a few months ago but never shared it with anybody, although I wanted to. So, I decided to blog about it.

You may now wonder what this is about. I’ll start from explaining the problem first. When you build kde from svn and install with a simple “make install” in your home directory, sometimes you face the problem that the obsolete files that were removed from svn and are no more installed stay in your installation directory forever, taking space, sometimes also causing trouble, and the only remedy is to wipe out the installation directory and install everything from scratch. When I first started building svn snapshots of kde, I had faced problems due to this (for example, problems with plasmoids not working because simply they were removed and thus the versions I had were linking against older and incompatible libplasma…), so I decided I had to do something about it. After some digging, I found that cmake lists all the installed files in a file called “install_manifest.txt” in the build directory, so I wrote a small program that finds the obsolete files by watching the differences in this file between two different installations.

You can find it here. Initially, I had written it as a shell script, but later I realized that the code had a serious bug and to fix it I needed some data structures (a set to be more specific), so I rewrote it in C++ using QtCore. As a side effect, rewriting it in Qt made it portable 🙂

How to use it

1) Get the file and compile it. A simple “g++ cmake_install.cpp -o cmake_install -lQtCore -I/path/to/qt/include" will do. Alternatively you can set up a qmake or cmake project file, but it’s not really worth it.
2) Put it somewhere in your $PATH. I use ~/kde/bin for this purpose, as it’s where all the kde trunk binaries get installed.
3) Adjust your scripts to call “cmake_install” instead of “make install”. If you use the scripts from techbase, then you can do this by editing the “cmakekde” function.

Note: As this program relies on the existance of “install_manifest.txt” in the current working directory, it should only be invoked from the root of the project’s build directory (for example in ~/kde/build/KDE/kdelibs, but not in ~/kde/build/KDE/kdelibs/kdeui). If you want to just install a subdir of a project, you can still use “make install”, if you know that there are no changes in installed files or you can clean up manually obsoleted files. Also note that the root of the project build dir is specified the first time that you build the project. For example, if you build the whole kdesupport once from the top level directory, the install_manifest.txt will be in the kdesupport build dir. However, if you build the projects in there separate (i.e step into phonon/, build, install, then step into akonadi/, etc..), each project will have its own install_manifest.txt, but then you can’t use my program to install the whole kdesupport from the root dir, you have to install the sub-projects separately.


Being a Qt program, this program is fully portable. I have used it successfully in linux, freebsd and windows without any issues*. For platforms that make is not called “make” you just need to set the environment variable MAKE to whatever your make utility is called. For example, on windows/mingw you have to call “MAKE=mingw32-make cmake_install”

* Well, windows vista and 7 have an issue if you have UAC enabled. Because the word “install” is in the executable’s name, windows thinks this is an installation executable and executes it with admin privileges in a separate terminal. To fix this, either turn off UAC, or rename cmake_install.exe to something else (for example, foo.exe will work :P).


5 thoughts on “Introducing cmake_install

  1. How does CMake know what to install if there are no per-subdir manifests? The answer to that question should help fix the subdirs problem…
    FWIW, I install to /opt/kde4 and I have a setuid-root helper tool to run make install (and only make install) as root.

  2. Generally, to clean up installation, you can install into temporary location, and use rsync to delete obsolete files.

    rsync provides more control to check what files should be kept, and may be run at any time. Your program seems to fail if run make install without it. And make install is easily called from VS solutions.

    However, your program is much lighter than rsync for everyday use.

    1. The method that you suggest takes twice the disk space and time that my method takes. I had thought of that, and it’s quite similar to how package management utilities work, but I needed something lighter and faster. It may have many limitations (works only with cmake, only from the root of the build dir, only by invoking cmake_install instead of make install), but it does the job I need.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s