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
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
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 8631dbf85f and
29042d096a that were the cause of the
problem described fdo#49921.
Change-Id: I9995002a2bd5c3604bdfa06dc817916ce61c558d
With the way dep-file generation was changed for LinkTargets in
8b5a984d45, 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
8b5a984d45 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.
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
