This commit for the old build system. (Don't bother for components not
relevant for Android.)
The Android package installer (as invoked through "adb install", from
"ant debug install") silently ignores native libraries in app packages
(.apk files) whose names don't start with "lib" and end with ".so".
The package builder (as invoked through "ant debug") in the SDK gladly
includes also thusly named native libraries in the .apk, though. Yay
for consistency.
The goal is to able to do partial build without having
to source Env.Host.sh into one's environment
There is 2 way to use this:
1/
copy the scripts lo_find_src_root and lo_proxy_start
somewhere in your PATH, and
then you can add
alias build='lo_proxy_start build'
alias deliver='lo_proxy_start deliver'
in your .bashrc
at that point you can use build and deliver anywhere in the source tree
without the need to source anything.
This allow you to switch from one source tree to another.
the proper SRC_ROOT will be determined automatically based
on the current working directory
2/
source build_env
build_env only source the bare minimum to allow build and make to work
for the associated source tree.
If you want to work in a diffrent tree, you need to resource
Do use NativeActivity and android_native_app_glue after all.
I hope this enables us to have a "message pump" (a loop that typically
would call ALooper_pollAll()) inside the LO "program" being run, as
expected by LO code.
(On Android, a "program", even one mostly implemented in native code,
is actually a shared library loaded by the main Java code of an app.)
The android_native_app_glue code and the android_main() it calls
belongs in the bootstrap library, though. Not in SAL_MAIN_IMPL.
The earlier idea, having a "normal" Java Activity subclass, would mean
events come in as method calls to that class. To then turn those into
something the LO code can "get", we would have effectively had to
re-implement what android_native_app_glue does anyway.
* solenv/bin/createcomponent.xslt simply surrounds it output by <components>.
* solenv/gbuild/CppunitTest.mk got new functions
gb_CppunitTest_add[_old]_component[s] (like their gb_RdbTarget_ predecessors).
* This obsoleted current uses of solenv/gbuild/RdbTarget.mk, which also does not
work currently, as it catenates the input component files instead of passing
them through packcomponents.xslt (which now takes care about the surrounding
<components> in the input). In the future, it will likely be combined with the
recently added solenv/gbuild/ComponentsTarget.mk.
a lot of configuration/definition is shared between platforms that build
using gcc.
This start to regroup things that are common into 2 files
com_GCC_defs.mk and com_GCC_class.mk
this can be expanded to be, more generically com_$(COM)_defs/class
The reson for 2 files is that some step need to modfify common definitions
based on the platform and some common definitions need platform defined
value.
with these 2 files we can do a
platform - compiler - platform - compiler - platfrom
sandwich that should cover every scenario.
