The goal is to manage LibreOffice configuration centrally
in the enterprise. In Windows Server environment using
Group Policies is a common solution for configuration
management. Therefore it is required that LibreOffice can
read configuration data from Windows registry, too.

Windows registry is another configuration layer on the
top of normal xml based configuration.

For example the following registry setting:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.UserProfile\Data\o]
"Value"="Example Corp."
"Final"=dword:00000001
becomes the following in configuration:
<item oor:path="/org.openoffice.UserProfile/Data">
    <prop oor:name="o" oor:finalized="true">
        <value>Example Corp.</value>
    </prop>
</item>

Change-Id: I2cdd83fc93922bf2806417bfd1b83f85cc926d4c
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>

Some of it is not in OUTDIR at all any more.

Change-Id: I1afbaafa0fe5a355158b44fcafd3d3e190fce79c

Change-Id: I90a96420c3261ce14f337dae3dfddfc01ac2436e

Change-Id: I34df96334478b10f151e630188f45e6ce0487f1a

Change-Id: Ibfd017c23cf510bf481d60b1e836654fd7240df0

This is mainly in order to determine whether the firebird ODS is safely
portable -- if testIntegerDatabase fails on non x64 / non Linux / non LE
platforms then this isn't the case.

Change-Id: I44eb7a774650cec27748b2058e9bb153f32742dc

This opens an "empty" firebird-based .odb and tests that it is possible
for the firebird-sdbc driver to open the embedded database.

"empty" denotes that the .odb is marked as using embedded firebird
but doesn't in fact contain any .fdb file within. This is usual state
of a .odb directly after creation using the "New Database" dialog when
the sdbc driver first opens the database.

Change-Id: I83941c05b6328d8419dca49121988640c6f887bc

Change-Id: I15ba6f0ffc645746be8deb83bc623a340b76bda9

Change-Id: Iec2db10104e79406cb2b9b6bac81d64dbe597d8d

Change the order of words BORDER and EQUAL in the
macro name to become consistent with other macro names.
e.g. CPPUNIT_ASSERT_DOUBLES_EQUAL
Use a function inside the macro to make it type safe.
Add additional message to make clear why the test failed.

Change-Id: I9fc7a5813adf2cac36ae831d438cec498232b06c
Reviewed-on: https://gerrit.libreoffice.org/5885Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Version independent ComponentID in Component table of MSI means
that the GUID is calculated from the Component name only, the
PRODUCTVERSION is not concatenated to the name. Providing that
name is constant in all versions, the resulting GUID would be
the same e.g. for 4.0, 4.1, 4.2 etc. But what is it good for?
Faster upgrades maybe? But name can also change, we did not
pay attention to keep it constant. So in order to help scp2
cleanup, VERSION_INDEPENDENT_COMP_ID flag was obsoleted and
removed.

Change-Id: I8e1ee450524b02f07d0b0553f6b82d0321dbddcf

Change-Id: I3d5b92d9890d6525b05575760a9fb4b4db65172b

This commit repairs broken link liblcms2.so -> liblcms2.so.2.0.4 as
liblcms2.so -> liblcms2.so.2.

Change-Id: Idccd65bba5cec822d285859f609e222c84f2fad9

Change-Id: I9c3c0d742bc2941fcf40ad69bfb744a57b3e7be6

Change-Id: I5831080411f6a759f5ebd8fbac840b8fb40be878

svx_unoapi svx.AccessibleShape on Windows:
One thread in ChildrenManagerImpl::GetChild() calling eventually
SdXShape::getPropertyValue() blocking on SolarMutex,
other thread calling ChildrenManagerImpl::CreateListOfVisibleShapes().

Not obvious if it's possible to release the maMutex in GetChild() around
calling ShapeTypeHandler::Instance().CreateAccessibleObject(),
since other methods here call GetChild() with maMutex locked themselves;
so just give up and use the SolarMutex in ChildrenManagerImpl too.

Change-Id: I9bf4e5926c4d01308513b1b4e88f20f9fd4c5648

... in finite time; waiting forever may hang the smoktetest in case uno
fails to start.

Change-Id: I42be4cecb8eec82df8f2df63f02e1223e4933626

At least the PythonTest will pick up the one from platform makefiles.

Change-Id: Ia1c3c0535529f4051f66d0ce91c377108a1a3cd7

Change-Id: Iea2a3d5d73ae6decb12082d850afd72514ef21a0

Change-Id: I001563c8aaf4e21e57c53aa2045b6709a35464d7

This commit breaks linkoo.

make dev-install continues to work as before but it's not necessary to
use it anymore.
make check now uses files copied into instdir by gbuild.
TODO: fix remaining issues so that instdir is the same as install/.

Change-Id: I66836170f0922ee9ba204a61ffacc30d9e9a5d98

Change-Id: I516abd165f947c155f3e969e27f51fb093bfa8fc

There should be only two ways how to add file into instdir:
 - gb_Helper_install used in gbuild
 - gb_Package_set_outdir used also elsewhere,
   preferably with scp2 containing its .filelist.

Change-Id: I75ec0ba63f32acf4b56b17dc972f4488edf6a777

Change-Id: I474881a5713dd2e09fdb47a683dc79f97f014b6b

Change-Id: Icfafff9120cae51c32ebfd87267e664f18f7ec8a

Hopefully the VERSION_INDEPENDENT_COMP_ID is not actually important?

Change-Id: Iad6e4eacffddf630768d89dbed391839144115ca

Change-Id: I980307749c5fb6f3682374e091bbcb91cdebd5fa

Change-Id: Ie88e74f3ced7595ab4a9dfaa16c2a4ce53bd7b3c

Change-Id: Iad3013df716f1dff66813e26c62d3275d5af2999

Change-Id: I1152270fe9579bc1f5eeab0d1a1d4b9673f6a7ad

Change-Id: I3a9cb4ce71cfb02b7378289a36aa0eb6e3a42f26

Change-Id: I4b41f8c2c6dd82956cb2493676c9854744eecbad

Change-Id: Id55fc6efcd957de926df79ca02200f4fda7c56b0

Change-Id: I194671feef281e07507e829fa43576f6a4468edf

The previous commit changed several nodes in main.xcd from
LibreOfficeDev to LibreOffice; revert that.

Change-Id: Ib1c114a0716a6a930c52c9c9a9144154fcb3934d

In main.xcd we have some variables which used to be defined mostly
in instsetoo_native/util/openoffice.lst and replaced in installer.
Process the file in custom target,
so we can copy correct main.xcd directly with gbuild.

Change-Id: Ie2b1b6da1adb161394f69c345bbe8671cfafb7c4

Change-Id: I9e9c0eee26ead63c508ddcd0dead60395e461aa5

Change-Id: Ieda9b3847de3de8989eaafc542e60216baa1af4d

Change-Id: I98b6263a464b46075e69e363c3eb9e4ec4557c46

also odk: better use gb_Library_get_runtime_filename than manually

Change-Id: Ibbded4e8279b5dcb452f0d90be755edee1d2b63f