As such, personally I don't see the point in uploading daily builds of
there boring useless test apps, but maybe it is good for marketing.
Change-Id: I6601107719ed28b72e239a2af8b7e3578ee3388d
as there is a corresponding property available since Api Level 14 that
is already used in the corresponding stlye definition.
Not a problem if older versions of android ignore that and don't show
the string in caps.
Change-Id: Ia9d5e32242bfc83370524011d11854f2c08348ba
Put cui and spl into extended_code and ignore the rest.
Also change DocumentLoader and LibreOffice4Android to use only
extended_core and writer as all the ios apps do, without knowing what is
really needed there.
Change-Id: Ic6a256ea47cc96132c0e7658d6ef2838b295ca71
It still seems to work for me.
Probably we do not need more components, but it's small enough for now.
Also add uui into 'core' group.
Change-Id: Ifadea8aa819ed17bbd021a0fa2373e6287e06446
Group logic from include/osl/detail/component-mapping.h has been
duplicated here for now.
The plan is to reuse this for iOS too if possible.
We don't need component-declarations.h now, which is good because
the list of implementation constructors is going to grow a lot over time.
Also, something needs to be done to avoid component-defines.h.
--constructor parameter was removed because it was not used
and also does not make sense.
__attribute__ ((visibility("default"))) is removed too.
Change-Id: I5e3f988800303d31e1d78220cbd25339bcbc482a
No one says this is the only good classification.
Quite possibly it's not even a good one, but at least something.
Change-Id: I81178314222f9f63708a83b262ff8ef73a1d9467
...to directly call constructor functions of ComponentContext-based C++
implementations of (non-single-instance) UNO services. The case where these
calls would need to be bridged across different environments (e.g., from gcc3
to gcc3:affine) is not yet implemented.
bootstrap.component and expwrap.component are adapted accordingly as a proof-of-
concept (which had previously been adapted to use the prefix="direct" feature,
which may become unnecessary again in the end, depending on how to handle
single-instance services/singletons). More to follow.
Change-Id: I18682d75bcd29d3d427e31331b4ce8161dbb846d
It's not terribly nice, but, hopefully, better.
The hope is that one day, lo_get_library_map will be no more.
In lo_get_implementation_map we can specify more precisely what to link
into the binary.
Change-Id: I99a1854fbae05be2f70302cc56bea88e522ec129
Demonstrating on expwrap library.
There is hope, this will bring code size savings for mobile
platforms, where we don't need every implementation.
Change-Id: I3519fb6148fd7a47ed9df092c73779ea6add552f
They were used to build metrics for printer built in fonts, which was
dropped in the previous commit.
Change-Id: Id9fb3108facec61eb6de0a2d16546f1187465e50
Reviewed-on: https://gerrit.libreoffice.org/6861
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Previously the Impress Remote app could only be built within
gbuild when building the entirety of LO for Android, it can
now be enabled separately to be built within any LO build.
(Note that the app could still be built separately without doing a
full Android build of LO by using the android build tools and/or IDE.)
Conflicts:
config_host.mk.in
Change-Id: I21d4389082a1492a3c9029d630f3fff97d9ba99a
Reviewed-on: https://gerrit.libreoffice.org/6146
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
It will be better to handle Android Impress Remote localization
independent of the big LibreOffice source tree. Instead of
stringex, we will use android2po, a 3rd party utility for conversion
strings.xml <-> pot/po.
Change-Id: I4eae53e4f8d94c55e5564d54c5e5c214bc9569d7
- WORKDIR path is just workdir
- INSTDIR path is just instdir
- WORKDIR_FOR_BUILD is workdir_for_build
- INSTDIR_FOR_BUILD is instdir_for_build
- replace other usage of INPATH by combination of OS and CPUNAME
Change-Id: Ie398387ebd82a968ec2605f2103c55b43a231482
Reviewed-on: https://gerrit.libreoffice.org/6601
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
We really should set up this list of all the libraries (even one including
wildcards) in a single place in configury. Now this information is duplicated
in several places. (Such a list is used when linking a single (app-specific)
DSO for an Android app or a single executable for an iOS app.)
Change-Id: Ic77bdd5a4e58686693f4ac3987ba73bca011db3b
