[cmake-developers] Building executables as libraries

J Decker d3ck0r at gmail.com
Sat Mar 22 01:51:50 EDT 2014


I think this is impractical... the native activituy doesn't provide a hood
to call 'main' and while you may have special code to treat main as an
export and dynamically load it, actually stubstitute the single program
with a loader dll and the program as a DLL, and the loader DLL has custom
code depending on the package. The reason to do this is to support a
package that support multiple entry points; the library and class name must
be different to have a separate launcher icon


On Fri, Mar 21, 2014 at 8:44 AM, Stephen Kelly <steveire at gmail.com> wrote:

>
> 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.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140321/0459a811/attachment-0002.html>


More information about the cmake-developers mailing list