Change-Id: Icd188e92a827a35239c708b5fa65f58fa670e1a5

Change-Id: I99688bdfd91d2591def46829b7579f2fada86f53

Change-Id: I217b41f966220b8b1ee9638d3f6a31a23dc4bf2e

Change-Id: Ifde9cee65b2bee731e66a200b3bf68c0e320872f

Change-Id: Iecfac54143676c9f0b483c4fa8deb26bf42ea16b

Change-Id: I0e6b29987381380e22aeaf07725e04de4ae76c54

Change-Id: I0d1802ebcf384095a6962fb1faf9516bd9a2dda6

Change-Id: Idfa3bae5c2caeee1a9a3e00f6aa6f8a18c7bde7c

Change-Id: Ifb9f4627c15d5f1410af2b87bf2e2f39c945671c

Change-Id: Ie1ca2df3e4b60c69a3c7860fe39aca4a505feffb

Change-Id: Ic93ec84ce62234364d233a9188a65439e88a79fe

Change-Id: I80a26483c4ecd099a1cfe76bdac1e97b947ef104

Change-Id: I7c3409ac39e690fcf2f7e4085bf6857e6bd182fb

since 99bf0c31

Change-Id: I0fbd88d842f750d101e3eec5a6b18f7e8bc062be

Change-Id: I78108f44bad1da0143f2849aa98a2ddf1b13fc1d

Change-Id: Ibfda0e6e65d0834cffdd95d4c6d87d07644088f6

for "add" an unknown word to user-defined dictionaries
a) use a normal button when there's only one user-defined dictionary
b) use a dropdown when there's more than one user-defined dictionary

Change-Id: I8a8eb3fff6c4582341d8322df403b73a517a5560

a) merge them together and move it into comphelper
b) turn it into a POD rather than having vast amounts
of destructors registered into the cxa_atexit chain

Change-Id: I04d3b9d7804f8e233013c916df9d617a0f84f96a

Change-Id: Ic7426d9838bb1034618c3d553482256d1866878f

Change-Id: Ib2642e19d9148acca27227b0d91de4e8855178aa

Change-Id: I104af905eb0d13864f70f44386b2b573fb26e513

Change-Id: Ie7d17f0ceb2e549b84c0cc16768604511e0e51a5

Change-Id: I7cae514cfd3c51bde5e8e0df2c51bed23904569d

Change-Id: I2a361a2c9becece74d41cb917a789a4429b3f3c1

Change-Id: I2254628edfe213c3424dce2bc5d9f164752e913c

Looks like there should always be a floor border for the 3D charts.

The only task of the UnoApi class is to deliver a RDB file and all the
stuff related to it (i.e., the IDL files and the generated headers). For
that purpose, order-only dependecies are sufficient.

Change-Id: Ibe0a58d1e8ceaad62ff71773e372fb8dfb921fbd

This reverts commit 07c0b800.

Change-Id: I4cfe3ce7b7dab5d3fb2d3ddfa28f0fa263593667

The reason is that they can be combined arbitrarily in dialogs, so
changing, e.g., height of one tab can lead to "interesting" results. Cf.
commits 8631dbf8 and
29042d09 that were the cause of the
problem described fdo#49921.

Change-Id: I9995002a2bd5c3604bdfa06dc817916ce61c558d

Change-Id: I1044c84dc0fb22188100c17440a72c0a7d923adc

The target is always older, because it is delivered while preserving
the timestamp of the source, but here order only dependency is enough.

Rules that invoke generated executables should have dependencies on
those executables.

With the way dep-file generation was changed for LinkTargets in
8b5a984d, it is necessary to change all
other dep-file generation the same way, because the LinkTarget dep-files
are outdated wrt. the object dep-files after an initial make run, and
hence if any other dep-file depends in any way (even build-order) on a
generated Executable, say by depending on the corresponding target file,
then the PHONY entries in the outdated LinkTarget dep-files for the
executable and its linked libraries cause all these objects to be
recompiled.

It is not a problem that there is a rule with the dep-file as target,
and another rule for the corresponding actual target that writes the
dep-file as a side-effect, without dependecy between the targets:
because make does processing in 2 phases, first building all included
makefiles, second all other targets, it is guaranteed that the 2
commands don't race to overwrite the dep-file because (when there is no
dependency between them) they will not be executed in the same phase.

The only problem here is that this will probably make IDL processing a
lot slower on Windows, writing all those dummy dep-files.

The LinkTarget dep-target depends on the LinkTarget headers target,
which appears unnecessary and harmful because since commit
8b5a984d the initial dep files always
contain PHONY deps anyway; also the PHONY deps cause spurious re-builds
here because e.g. the tools library depends on a tools package that
depends on a tools custom target that depends on some executable
that depends on libuno_sal that depends on its objects which depend on
this PHONY thing so all that stuff is spuriously re-compiled in make
subsequentcheck after a build from scratch, breaking tests because
being subsequent they don't expect libraries to change under them.
Also, link target shouldn't depend on its dep target.

The OUTDIR RDB depends on Packages for IDL and headers, the latter of
which depends on the WORKDIR RDB, hence preserving timestamps here leads
to spurious re-delivery because the OUTDIR RDB always has older
timestamp than the headers Package.

idlc breaks because sal considers X:\\foo an invalid system path

We might eventually want to use Mike Hommey's "faulty.lib" dynamic
linker (developed for Firefox on Android) to get around the Android
system dynamic linker's silly limitations. It does not like
DT_RPATH. (The Android system dynamic linker just ignores those.) So
no point putting RPATH into the ICU libs for Android.

Note that the faulty.lib linker is not usable currently because it
doesn't like the text relocations that the NDK r8 toolchain generates
for some reason. Sigh.

Change-Id: I9092c6001f0aadbb30e2682e33e7179520846f3b

At least with sw_complex test under load, it happened that an ORequestThread
could still process a remote release request while the main thread was already
in exit(3).  This was because (a) ThreadPool never joined with the spawned
worker threads (which has been rectified by calling uno_threadpool_dispose(0)
from the final uno_threadpool_destroy), and (b) binaryurp::Bridge called
uno_threadpool_destroy only from its destructor (which could go as late as
exit(3)) instead of from terminate.

Additional clean up:
* Access to Bridge's threadPool_ is now cleanly controlled by mutex_ (even
  though that might not be necessary in every case).
* ThreadPool's stopDisposing got renamed to destroy, to make meaning clearer.

Change-Id: I45fa76e80e790a11065e7bf8ac9d92af2e62f262

Change-Id: I9dbe77062df3a9b02dab0f5755c0e616829fa125