Icinga 2 on Windows: Build Packages

Follow-up from the recent blog post on developing Icinga 2 on Windows:
Now that we’ve learned how to compile and develop Icinga 2 on Windows, it’s all about running it and also creating a setup package for installation.
 

Build Release Package

CMake uses CPack and NSIS to create the setup executable including all binaries and libraries in addition to setup dialogues and configuration. Therefore we’ll need to install NSIS first.
Once completed navigate to your Visual Studio project and tell CMake to build a release package.

cd "c:\Users\michi\Documents\Visual Studio 2015\Projects\icinga2"
cmake --build . --target PACKAGE --config Release

icinga2_windows_cmake_build_exe
Note: This will still use the debug builds from the previous Visual Studio integration guide. A yet more clean approach is to run CMake with changed release parameters beforehand and then re-run the release package builder.

cd "c:\Users\michi\Documents\Visual Studio 2015\Projects\icinga2"
cmake . -DBOOST_ROOT=C:\boost_1_60_0 -DBISON_EXECUTABLE=C:\ProgramData\chocolatey\lib\winflexbison\tools\win_bison.exe -DFLEX_EXECUTABLE=C:\ProgramData\chocolatey\lib\winflexbison\tools\win_flex.exe -DICINGA2_WITH_MYSQL=OFF -DICINGA2_WITH_PGSQL=OFF -DICINGA2_UNITY_BUILD=ON
cmake --build . --target PACKAGE --config Release

The CMake instructions are defined inside the main icinga2 git repository in CMakeLists.txt (look for variables with prefix CPACK_).

Run Icinga 2

While you can run the icinga2 daemon in foreground, you should be well aware that the default mechanism is to install a Windows service and let it handle the start, stop and reload actions for Icinga 2.
Apart from that you may just use the icinga2 cli commands known from the documentation, such as “icinga2.exe daemon -C” for validating the configuration on your Windows client.
Another example: “object list”
icinga2_windows_object_list

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Weekly Snap: CMake, Rsnapshot & MyPhoneExplorer

weekly snap4 – 8 November offered new ideas for build systems, backups and smartphone syncing, as well as a Puppet Camp and webinar on the side.
Ronny recommended MyPhoneExplorer to manage and sync SonyEricsson and Android phones on a PC.
Eva followed with a reminder to snap up the last few tickets to Puppet Camp in Munich on 28 November as Christian reminded interested participants to join our webinar on Graphing with Graphite.
To close, Gunnar put the case forward for using CMake as a build system and Thomas offered his tip for quick and dirty backups.

CMake als Buildsystem

Unter Linux ist autotools der Standard, wenn es darum geht, Anwendungen aus einem Source-Tarball zu kompilieren. Weit weniger bekannt ist CMake, das allerdings einige Vorteile bietet.
CMake selbst ist eigentlich kein Buildsystem. Es erstellt lediglich für andere Buildsysteme Projekt-Dateien. Unterstützt werden dabei Makefiles, Visual Studio, Xcode und etliche mehr. Wer z.B. primär autotools verwendet, aber parellel dazu Visual Studio-Projektdateien anbietet, spart sich so, diese bei Änderungen nachzupflegen.
Bei CMake funktioniert “make -j” über Verzeichnisgrenzen hinweg, wodurch die Buildzeit verkürzt wird. Der Effekt ist besonders spürbar, wenn das Projekt viele Unterverzeichnisse mit jeweils nur wenigen Dateien beinhaltet. Mit autotools geht “make” jedes Verzeichnis einzeln durch und wartet, bis das jeweilige Verzeichnis fertig-gebuildet ist.
CMake liefert für viele Libraries eigene Scripts mit, die dabei helfen, diese in das eigene Projekt zu integrieren. Für autotools gibt es zwar etwas ähnliches (GNU Autoconf Archive), aber die Qualität dieser Scripts lässt zu wünschen übrig. Manche der Scripts funktionieren z.B. mit den Library-Pfaden von neueren Debian-Versionen (Stichwort: Multiarch) nicht mehr.
Nicht zuletzt ist die Syntax von CMake deutlich eingängiger und einfacher als die übliche Mischung aus Shell-Script-Schnipseln und M4-Makros bei autotools.
Als erste Anlaufstelle für autotools-geplagte Entwickler bietet sich die CMake-Dokumentation an, in der detailliert alle Befehle erklärt werden.