Age | Commit message (Collapse) | Author |
|
Change-Id: I64995db8f9e913db5f4ab4e81359dd163bc29d15
|
|
Change-Id: I6b26f2805d08d2eb1b28ade459d38a1c6895addf
|
|
Change-Id: Ia212489c33da72f85d96618aa1d4db5972044bb2
|
|
Change-Id: I62c5f9206b6bc0321b7ee2b9c679ab7b5400a8ef
|
|
Change-Id: I2bbc2763eca7c878ead2a325589d8c4bb9210bda
Reviewed-on: https://gerrit.libreoffice.org/868
Reviewed-by: Marc-André Laverdière <marc-andre@atc.tcs.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie2c7b219f57a2bdf14fc07311a03a2c66f6c75aa
|
|
Change-Id: I4359784279875dc9dac99bc4d2db95dccf094b20
|
|
Change-Id: I1dda0f2b3bc2bb4a4a877c160026e53a90471d54
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
|
|
fix up some indents, remove some unused OUStrings and add some log areas
Change-Id: I5c50807aff7a726b03b72522975d9b75e6685b9b
|
|
Some of the areas are guesses I've added after seeing them, whoever feels reponsible
for whichever part of the code feel free to adjust them.
Change-Id: I2192de84d51cc2bc7c28fa84019d38b465985d15
|
|
Change-Id: Ib5e606283d3d37c38e9729c79c4531807a1419d3
|
|
http://lists.freedesktop.org/archives/libreoffice/2012-October/039639.html
Change-Id: I1a0e436051d48e7f6224d6f0fc602347df2d4df1
|
|
Change-Id: I4f3a51e1fd3ddca9442022a7134306fbf32e13ae
|
|
Change-Id: Ice88c3912c2fd0d99156acaa8e15518acab3b55b
|
|
Change-Id: Ib918bd537b30fe5dc48396fc7e952147003e3b19
|
|
IN this branch these changes are not conditional. Unclear yet whether
this is what we finally will want to use or not. Maybe should make
these changes conditional and do this stuff in master instead?
Change-Id: I379d570a0e00648d295c675fd90eba6594ba3182
|
|
Change-Id: I8847192f61b2fca696a1ec6fbad65026e1ffdb43
|
|
Change-Id: I020149a3073d8479887d108465cf5d3b727588d7
|
|
This method will be needed for forthcoming String->OUStringBuffer
conversions.
Change-Id: I001099baaca5cd402aebcd15c031d9060286a8f9
|
|
Change-Id: I420229dea6c5b3e45cec5989897bb31654851e32
|
|
This is for variables that the compiler itself cannot figure out
(e.g. non-trivial ctors). The classes need to be marked manually.
Change-Id: I0109972e11e20578b1adc32065f701a871ee21aa
|
|
Will then cause compilation errors where they are used, which will be
noticed and taken care of. (The code chanaged to either use direct
linking instead, when it makes sense, or to just bypass the
functionality that requires dynamic loading.)
Much better than waiting until run-time to notice where dynamic
loading is attempted.
Change-Id: Ib0cb5a2524b5c63f8e27670e7d72e37ce2a8e6e9
|
|
Change-Id: Ib5da7703bf48713093bc6a3380facafd0013e039
|
|
This reverts commit 563fa900ba22bf83dfa58e67807ed0337f810576.
|
|
Change-Id: I2cbb4d126b27c5cb7a1be3606807fcbda25d3e72
|
|
Change-Id: I43bad91f6afe5b55c6e2b6bf952cc0291d5bdd10
|
|
Change-Id: Idba65371b8778521bc767fe4893340cf13a8ff3b
|
|
Change-Id: I03bb4db5931932280e368012cbaee6bef2854dd6
|
|
Change-Id: I43650c6f4a66058e73945851a6990555e42b8ac2
Reviewed-on: https://gerrit.libreoffice.org/744
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I91a7f74e55b6ad8780a3a0920a22b6a7264b7b88
|
|
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
|
|
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
|
|
Change-Id: Ia7f64bdd0fd81c5dcc08d828db4602b65e2da949
|
|
Change-Id: I66f8229e186e312ed3242695db9ef0768ab4d9a0
|
|
There are currently 3 different mechanisms being used for frameworks,
which is of course intolerable so we invent a 4th one and standardize on
it: gb_LinkTarget_use_darwin_frameworks
(This doesn't mean using add_libs or externals was wrong, it was just
inconsistent... and i don't see an obvious benefit of using externals here)
Change-Id: I5de9020402c87e7236c6a358c47f02fa56642d3d
|
|
... new gb_LinkTarget_add_standard_system_libs
Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
|
|
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
|
|
Change-Id: Ib33d91ea56219036182d30fdd3dc2159ce32a48c
|
|
Change-Id: I1d755086295f5a8cd7acf56204402b95fe228d2d
|
|
Change-Id: I93949cc37821c5306514c8ce2f21519550f33775
Reviewed-on: https://gerrit.libreoffice.org/672
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: Ifcfa48fc87f905a91470a5b0fd597b02f220784c
Reviewed-on: https://gerrit.libreoffice.org/671
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I0733abb5c736ab393259fd6a005a89b887304f10
|
|
Change-Id: Id9c452d9c1034f2e7969a9eae7588f2eb81a8813
|
|
Change-Id: I95d23e6728571b3f3a6421a05fec814f7c5d059c
|
|
|
|
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>
|
|
It apparently works that way, so there's no need to have
an #include loop.
Change-Id: I58d4f0461c14637872a139f0fbfb78f2a99fe28a
|
|
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: I33fbe68b17e9a1c457b37c6d81619f2df67fbe8d
|
|
atomic increment/decrement is provided by
osl_increment/decrementInterlockedCount()
but that is a exported dll function, so it cannot be inlined.
valgrind analysis of a run, loading a medium sized spreadsheet, shows
that these 2 functions were called 3.5 millions times for a total cost of
55 millions of instructions... a cost of 8 instructions per call,
which is at least a 300% overhead since an atomic inc/dec is 2 instructions
iow we could save about 1% of the total instruction count of that run(4.6B)
We cannot change the existing api, as this would break ABI.
but we can add a new api. and migrate internal user to it.
osl_atomic_decrement/osl_atomic_increment do the same task,
than osl_*IntelockedCount() but do that inlined if possible.
Note that this version only optimize the case GCC with atomic built-in.
but support for other case should not be very hard.
follows-up patches will replace the use of the osl_*InterlockedCount()
in the product with their osl_atomic_* equivalent.
Change-Id: If4dcbf94ea6f62eb6d55d30613fe65878ffb8023
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|