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 <[email protected]> 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 >
-- 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
