Age | Commit message (Collapse) | Author |
|
Change-Id: Ia8a644c613de17279abdab533a6314ba6c0e0aec
|
|
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
|
|
... new gb_LinkTarget_add_standard_system_libs
Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
|
|
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
|
|
Change-Id: I0733abb5c736ab393259fd6a005a89b887304f10
|
|
Change-Id: I65f09e54c80df4e96e24548692eeb3a57e1de517
|
|
Change-Id: Ie1ff96b6f58bf694b8d08a3316144becaaefe6d9
|
|
Change-Id: I5e966a5734308381ad305b891ecfc830dc1419f6
|
|
the intent of this header has canged over time. now it is already
systematically included with ustring.hxx and the operator overload it
provide fit nicely there...
Just to be safe, since that include as been added to the api during the
3.5 timeframe and therefore is already in 'production'
the header remain and simply attempt to include ustring.hxx
but a warning is issued indicating that this header should not be used
anymore... in a couple of major release we will thenr emove it completely
All internal users of that header are converted.
Change-Id: I8934c55f089e29d78c0f5649b7c87b2ecf024bad
Reviewed-on: https://gerrit.libreoffice.org/634
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I0e6992afbeffaf3b993e6630fb396d93012890e0
Reviewed-on: https://gerrit.libreoffice.org/632
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I78c71b22816834c66c8283e3d85e357b7b8d2836
|
|
Evidently on Windows, the newfangled ucpp handles #include "foo"
differently from #include <foo> and treats it as a relative path, while
the angle brackets always result in absolute paths.
Since relative paths result in infinite rebuilds if make is invoked in a
different directory, don't use #include "foo" in IDL files.
Change-Id: Iedcda3a4be5542389a0be086f14541cda8dc5323
|
|
Change-Id: Ia49c97ad58b21dc360a366260b62bcc6b4975dee
|
|
Change-Id: I88976b215bc23ce5001916ccf123bc3561c2a33a
|
|
Change-Id: I234c615d9d3386da2b244709add5c029b76d346c
|
|
Change-Id: Ie355701716c7106ef2afd76ae8b6544a00ac474c
|
|
Change-Id: I8fdfbebd9fd4bf19b57ec83689116c6fc77227e6
|
|
http://lists.freedesktop.org/archives/libreoffice/2012-April/029940.html
The RTL_USING #define (set by gbuild for anything that's not public
API) allows to use such classes simply by their name, without having
to use the namespace or do explicit using rtl::OUString (which half
of the sources do anyway).
Change-Id: I7edaf12cd278489cdc1d5ff782f0a86361c13c0a
|
|
Change-Id: Id4210229b20a1d54b680ff1a2ccbcdd3684ecf5f
|
|
Change-Id: I425e7bcc8f81b2d67a98244ba4419ace1ba569ec
|
|
Change-Id: I6978524ef934ee97d151e0fd22f3a0dfc91fd26e
|
|
|
|
Those are unused too.
Change-Id: I09c9dbcdbc68131c7c54bf0762a23f1280e6e22a
|
|
|
|
|
|
Change-Id: I15e94f112144549692d0c2babeb48c77adcb93a9
|
|
Change-Id: I611dc412b5461f368f23aa8239e48d0e175f5168
|
|
|
|
|
|
|
|
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
|
|
Unfortunately this --enable-dbg-util only problem (caused by
_GLIBCXX_DEUBG) resurfaced, perhaps because of new std::string based
logging in sal; adapt all map files to export the unique symbol.
|
|
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
|
|
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
|
|
|
|
(This reverts commit 0ba6bd3ddc025666a6d4bb0640bf443728b23bd3.)
The problems worked-around there are no longer observed by me, so they
were hopefully only a temporal problem (the real root cause had never
been found back then). If problems start to pop up again, we'll need
to have another look at this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
Pattern used:
find . -name "*.cxx" -exec sed -i 's/\( *\)\(else if\|if\) *( *\([^!()|&]*\)\.equalsAsciiL( *RTL_CONSTASCII_STRINGPARAM *( *\([^)]*\)) *) *)$/\1\2 ( \3 == \4 )/' \{\} \;
|
|
|
|
|
|
|
|
|
|
|