[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