Change-Id: I39ce208c1e5dd307631c628217ff596632753f23

Change-Id: I91ca29d9960e2f92c0f8bdec97695b58078fac6b

Change-Id: Ia7eed5e9e1f8fba9876730e909461dabc167deb9

Change-Id: I3febbc1618ca86f19c851a8eea313327a9c0a96c

…instead of using eval to process the same rule multiple times
Saves quoting, makes it more readable.
(% always matches whole sub-paths, not only on Mac, see
http://www.gnu.org/software/make/manual/html_node/Pattern-Match.html)

Change-Id: I80e481d4a7e1cd62ad9916257a75c77c87d3bbdd
Reviewed-on: https://gerrit.libreoffice.org/858Reviewed-by: Peter Foley <jpfoley2@gmail.com>
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>

Change-Id: I16c40fceb2fc84147eb298aa86987b8682a81c8e

Its a nice idea to merge properties of the same type and value if one starts
and the same place the last one ended. But character styles are properties as
well, so if we have character-style+superscript on range a, and
character-style+superscript on range b and merge these so that we end up as...

character-style on range a, superscript on range a+b, and character-style on
range b then that clearly gives the wrong result if applied in that order.

So its only safe to merge if there are no intermediate properties that can
affect the merge candidates.

A regression from b3cee382

Change-Id: I541563d11265426736b840de068922eef8d45573

Change-Id: I892a77f65ad420d0fbf4b95179e4bcfc2ec55192

Change-Id: I96893aa0aed6144c3888a85afe64f90d969e9448

Change-Id: Ief0083c0274c573fce62c32dfae35a647804b20e
Reviewed-on: https://gerrit.libreoffice.org/900Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>

Change-Id: Ia68b74d06ffe533bcc302fb5094267e0efae6faa
Reviewed-on: https://gerrit.libreoffice.org/901Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>

In final (NDEBUG) builds assert expands to (more or less) nothing.

Change-Id: Ie6d43cac381975880c9db2b4a01bd9ed30e2714b

add error handling for fread, fwrite, and fscanf calls

use "fputs" instead of "fprintf" to avoid warning that it couldn't varify
the format string because it wasn't a string literal.

Change-Id: I1137160d28461fbac69c8e05d32ba010da491c57
Reviewed-on: https://gerrit.libreoffice.org/903Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>

Change-Id: I6a1d51e6a1e5e41b9866bc67c2e9707a2bd2e9a4

...the reason it started firing was a regression that has now been addressed
with 402eaced "Related fdo#46808: Fix
UUIInteractionHandler::initialize argument handling."

Change-Id: I2f36e1cb5ae1af293a7c07c366f1602e56e966ea

This was a regression introduced with c25cb8a6
"fdo#46808, Adapt task::InteractionHandler UNO service to new style."

Change-Id: I52e36c4aabbf4b2b4552ed0e8ea164db15071980

Change-Id: I452319aa627c8de17e87033597a151f186c4361c

...with its ifneq ... endif sections, so require make cmd instead here.

Change-Id: Ifab2117c5fb775c0c4ca7001f954716bd09a3844

Change-Id: I6613cad010267afa551ddcab7cf92c7d930d409a

Change-Id: Icdbb60525f858a2a0002a5e6f599eb6a6954a9dd

Change-Id: I81d0902ca41b8dcb43d58d47b9758b8718c25e86

The windows (dmake) build no longer needs uwinapi.

Change-Id: Ifcbee0c94ce55a59b46c5542cb42ede54c7d8b57

Change-Id: I29dd9d4e0a4dc342d28cb93a4cff65aa394848d4

Change-Id: I0ef147e1a86a7a88359c30c458e69cc5ac35741c

Change-Id: Id398311fe86dbd81e5d1cbdf129783e659973737

Change-Id: I13de2ea8cdd63cd2ba365a0ee02c224092d3f65f

Change-Id: Idaa56eb209e356c434804ce86b644b33773f44d1

Change-Id: Id643fc7bb16a4456dc6821efe44a8bc0e73d88f7

Change-Id: I47c279d1cf53ef2c092467070d97b13f949d06f6

Change-Id: I1d9e64bf16b7572de120e9f81e9f13c7c4c11ca0

Regression from d4069372.

Change-Id: I58e8d48ac3222b795f7edfd0e74ecd86ea36f380

Change-Id: Ia212489c33da72f85d96618aa1d4db5972044bb2

boost::detail::multi_array::ConstMultiArrayConcept

Change-Id: I8937079337eb3c4cfd29c03c6602b99b28f5c59e

Change-Id: I7c22869028a78f48836741a4eb4cd5bbff16e884

Change-Id: I98a3428578b52c6d9d7210a8fb0211876d6f7cae

Two different xmlparse libraries are created: ascii_expat_xmlparse and
expat_xmlparse. One without -DXML_UNICODE and one with. Source file are
duplicated and renamed with gb_UnpackedTarball_set_post_action function
to be able to add artifacts twice to gbuild machinery.

On windows 64 bit additional two librares are created: expat_xmlparse_x64 and
expat_xmltok_x64. That is due the problem with shell/shlxthandler (comment):
------------------------------------------------------
use UNICODE only because shell/shlxthandler
doesn't link against ascii_expat_xmlparse
------------------------------------------------------

Include files are delivered to $(OUTDIR)/inc/external/expat
now and not to $(OUTDIR)/inc/external any more.
set_include call is added in RepositoryExternal.mk.

To define dependency between StaticLibrary and ExternalProject
new function was introduced: gb_StaticLibrary_use_external_project.

Change-Id: I3b3aa40f39ef82c70f6f28790b582c83e48bdf76

Change-Id: I770cdbb23e9a42308e95505235378d715c1fcd79

Mainly because it seems we hit this assert several times and right now
it seems harmless.

Change-Id: I9176741dd25f405c9eb49daef9c703cfde4386c4

All the other messages are already > 1, makes no sense to have this as
> 0.

Change-Id: I816239903cef650f34d9c57446018843e2acb64a

… in this function"
declaring those functions static breaks the build on MacPPC / gcc 4.0.1

Change-Id: I3a389530d51ae0ddd38418159ca4234016bf93ba
Reviewed-on: https://gerrit.libreoffice.org/911Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>