[cmake-developers] Building executables as libraries

Stephen Kelly steveire at gmail.com
Fri Mar 21 11:44:03 EDT 2014


Hi,

For many years, KDE (on UNIX) has had a system of launching executables by 
forking the kdeinit process and loading the application code with dlopen. 
This allows avoiding the startup overhead of initializing Qt etc for each 
process which is started.

Launching the konqueror application from a UI such as the KMenu or KRunner 
will run something like 'kwrapper4 konqueror', which uses D-Bus to tell 
klauncher, which serializes such requests and uses a socket connection to 
kdeinit to trigger it to do the fork+dlopen.

For convenience, KDE creates both the dlopen'able library and a separate 
executable which links to the library so that the user can also just execute 
'konqueror' on the command line, bypassing the kdeinit system.

 https://projects.kde.org/projects/frameworks/kinit/repository/revisions/master/entry/KF5InitMacros.cmake#L14

Maemo used the same trick:

 http://katastrophos.net/harmattan-dev/html/guide/html/qtboost.html

 https://maemo.gitorious.org/maemo-af/maemo-launcher-qtbooster46-fremantle/source/158a316db5387752bd0be9655ee2b85b6dcc3999:README

I think BB10 can use the same trick:

 http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0ffea110c1/
 http://devblog.blackberry.com/2012/12/cascades-project-zygote/

Android requires native code to be loaded from java as a shared library 
using 

        System.loadLibrary("TestCMake");

to load a library called libTestCMake.so. The android packaging system won't 
even package a file if it does not have the .so extension. Console-only 
applications on Android may be regular executables.



Should we try to add first-class support to CMake for building shared 
libraries from CMake code like

 add_executable(...)

somehow? There would probably need to be some properties to control it, but 
I wanted to raise the idea.

Thanks,

Steve.




More information about the cmake-developers mailing list