Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
There are currently 3 different mechanisms being used for frameworks,
which is of course intolerable so we invent a 4th one and standardize on
it: gb_LinkTarget_use_darwin_frameworks
(This doesn't mean using add_libs or externals was wrong, it was just
inconsistent... and i don't see an obvious benefit of using externals here)
Change-Id: I5de9020402c87e7236c6a358c47f02fa56642d3d
Pass on to VirtualDevice where used to set the MapMode of the device
appropriately. Adapt DocumentLoader, use to scale the page rendering
to exactly fit the virtual device.
Change-Id: I4b0bc67e12114d3d9d493ff1aca2ef5d2cc78912
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
It's too small to justify standalone existence.
We can accumulate i18n things we link to directly into
i18nutil and rework i18npool uno implementions in terms
of thin wrappers over i18nutil and prefer linking to
i18nutil internally and leave the uno forwarders for
use by external components and scripting
Berkeley DB is used for help index and extension database. (Possibly
only for a backward-compatible format of the latter, I am not sure.)
Neither use makes much sense on Android and iOS.
The existing help is for LO on desktop OSes anyway, help for LO-based
apps on iOS and Android will naturally be quite different.
On iOS there will definitely be no "extensions", and probably we don't
want to bother with such on Android either.
Peter Foley