| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allow to run make in a module wihtout the need to source
Env.Host.sh.
|
|
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
|
|
Seems I mis-copypasted the name here - mac dev builds were not using
the new DS_Store at any rate.
|
|
|
|
With the basis/brand split undone, they are always the same as
PRODUCTVERSION and ABOUTBOXPRODUCTVERSION, respectively.
|
|
|
|
plus gb_Helper_extend_ld_path normalization by sbergman@redhat.com
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes the MinGW installation problems with officehelper.py.
|
|
* 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.
|
|
|
|
|
|
In a --enable-dbgutil tree, "make clean" will remove solenv/$OUTPATH.
|
|
|
|
|
|
|
|
That simplify the dispatching in gbuild.mk and gbuild_simple.mk
and it will be use as a base to factorize common stuff based
on OS and Compiler.
|
|
|
|
See my previous commit for rationale.
For Android, bypass the UNIXVERSIONNAMES thing in the dmake build
system.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
setting and using gb_Helper_set_ld_path and gb_Executable_EXT_for_build
is enough to factorize these out of platform/*
|
|
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.
|
|
|
|
|
|
Nah. Sure, doing it like that is sane if you consider only our own
code. But it won't help in making sure these options are used when
compiling the 3rd-party external libraries. For that having the
options already in the CC and CXX environment variables works nicely,
I think. People just need to look at the samples in README.cross.
Perhaps we could add the options to CC and CXX in configure.in,
though? Is that elegant or not, don't know...
This reverts commit 3c4f7242a967d6a3cb9e5e3f88bfb2cc348cc3eb.
|
|
The findrequires scripts are apparently ignored by current RPM.
Apparently an additional variable needs to be defined so they are used.
http://www.redhat.com/archives/rpm-list/2005-August/msg00034.html
|
|
|
