...which also needs a change to the logic that symlinks *.jnilib to *.dylib, as
that would have symlinked pyuno.so onto itself (as it contains no .dylib). (And
while we are at that, anyway, also only store relative paths in the symlinks.)
Change-Id: I6f3e9effc4d185df935795958cc84e60e862a424
avoids the problems of dangling uno singletons invalidated after the first
dispose and the chain of other singletons that don't expect to need to
re-initialize, etc.
reenable editeng cppunit test
inherit i18npool cppunit test from unotest base
drop LibreOfficeProtector, do "throwable" work in setUp/tearDown not
in ctors/dtors
Nah, these dummy classes would turn out quite complex anyway. Better
to just use ifdefs elsewhere, the number required is not that large.
This reverts commit 6d33801b4498f5c13d2dc75588f88c22a11f455b.
Work in progress, the dummy class implementations surely still
incomplete and/or might contain methods not actually needed. More
dummy class implementations needed, hopefully not too many
though. Will add also a few ifdefs for DISABLE_SCRIPTING in some key
places in sc and elsewhere to cut down on the need.
Otherwise the package creating code (part of the SDK) won't include
them and/or the package installation code (on the OS itself) won't
unpack them. (They just silently skip the file.)
Last fixes - remove kludge from RepositoryFixes.mk, have redland
build w/o threads for the while, and some hackery to exclude
pointless code like oosplash from android build.
The comment for gb_Library_ILIBFILENAMES in the WNTGCC case doesn't
make much sense for us, though, as I think we want to support WNTGCC
only for cross-compilation, and thus we don't have access to the PSDK
("Platform" SDK, with which they mean the Windows SDK). I don't see
any point in using MinGW natively on Windows to build LibreOffice. If
you build locally, use MSVC.
