Cloned bitmap devices may share the same chunk of memory, thus
risking overwriting our own data when we copy stuff around. Now
caught from unit tests.
Change-Id: I33b1a0b5d17550cbc6eced8bae01ae5ab9ebce9d
Equality test also needs to check if disjunct BitmapDevice instances
might not actually share the same memory buffer.
Change-Id: I09a93cb092a0039353be211ed053e991e7fe66f0
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
We don't run unit tests when cross-compiling anyway and since
d4ea8c6b7ee32dfbe1525cae45ad44d411052c33 the corresponding .mk files
aren't even read by Make.
Change-Id: Icbee9ad51841d515a551e67708d9594358ce7e71
To properly handle subsetted BitmapDevices in the iOS vcl backend I
seem to need to know what the size of the full BitmapDevice is.
I wasted at least one day on desperate hacking and debugging, trying
to wrap my head around a misunderstanding of what a subsetted
BitmapDevice is. I thought it involved coordinate offsetting...
Change-Id: I83bf1a7d75ce192aaf21f1e408008e362fd6c6e6
The value returned by getScanlineStride() is always positive even if
internally the scanline stride is negative in the bottom-up case.
Change-Id: Iaf394639d1e5a27d64b83f75c1d715a9860e492e
- do not use gb_UnpackedTarball_copy_header_files for boost
- adapt the optimization in concat-deps.c for new path
- use boost_headers in all LinkTargets that require it
- add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus
Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
Nah, just don't bother using --enable-werror with an old system
cppunit that has the unused argc and argv in
CPPUNIT_PLUGIN_IMPLEMENT().
This reverts commit 7e6689e3ed8972871718f6f8d06968efde264612.
This reverts commit 07b6dc8610785026860f6dfcf6aab1c4ad1f45f2.
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
* As UCB is only ever initialized with "Local"/"Office", remove this
configuration vector completely. The "create" ctor creates an instance
internally initialized with those "Local"/"Office" keys. Special (test) code
can still instantiate an uninitialized one via plain createInstance. And for
backwards compatilibity process startup still ensures to create an initialized
instance early, in case there is still code out there (in extensions) that
later calls plain createInstance and expects to get the already-initialized
(single) instance.
* XInitialization is an "implementation detail" of the UniversalContentBroker
service, do not expose in XUniversalContentBroker.
* ucbhelper/configurationkeys.hxx is no longer needed and is removed.
* ucbhelper/contentbroker.hxx is an empty wrapper and is removed; however, that
requires ucbhelper::Content constructors to take explicit XComponentContext
arguments now.
* The only remaining code in ucbhelper/source/client/contentbroker.cxx is
Android-only InitUCBHelper. Is that relevant still?
Change-Id: I3f7bddd0456bffbcd13590c66d9011915c760f28
For Android (and perhaps iOS) we need a 32bpp format with channels in
RGBA order.
Rename the (basebmp-internal) 32bpp PixelFormatTreats_* typedefs so
that the channel order in their names matches the memory order of the
channels.
Change-Id: Ia8a74f6d44e0a2cffdf66a05ddf8fc7d6ae2a263
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
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)
...which has the necessary features to support it.
Change a lot of classes to either contain a protected non-virtual dtor
(which is backwards compatible, so even works for cppumaker-generated
UNO headers) or a public virtual one.
cppuhelper/propertysetmixin.hxx still needs to disable the warning, as
the relevant class has a non-virtual dtor but friends, which would still
cause GCC to warn.
Includes a patch for libcmis, intended to be upstreamed.
Let's do the iOS specific stuff in separate main() source
file(s). Don't attempt to build complete iOS programs using normal
LibreOffice mechanisms, it will work for only the very lowest level
unit tests anyway, because of static linking and the circularish
UNO/URE/bootstrap/whatnot (run-time) dependencies between different
parts of the code.
We thus can't build the various iOS-specific *_cppunittester_all unit
test executables any more. Corresponding unit tests (and more complex
ones) for iOS will have to be done in a different way.
