Now that we have default values for Exception constructor params,
remove lots of boilerplate code.
Change-Id: I620bd641eecfed38e6123873b3b94aaf47922e74
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
...where it is correct and 336353a87e6003e685aab87ea74a158546e1f297 "Related
rhbz#867808: More apparently bogus 'throw new ...' in C++ code" had changed it
by accident.
Change-Id: Id7fc1adf8c0068a3b59794d156b21f68b5ac7e72
Convert code like:
aStrBuf.appendAscii( RTL_CONSTASCII_STRINGPARAM( "ln(x)" ));
to:
aStrBuf.append( "ln(x)" );
which compiles down to the same code.
Change-Id: I24c7cb45ceb32fd7cd6ec7ed203c2a5d746f1c5c
Convert code like
aStr.compareToAscii("XXX") == 0
to
aStr.equalsAscii("XXX")
which is both easier to read and faster.
Change-Id: I448abf58f2fa0e7715dba53f8e8825ca0587c83f
Convert code like:
0 == aStr.compareToAscii("XXX")
to
aStr.equalsAscii("XXX")
which is both clearer and faster.
Change-Id: I2e906d7d38494db38eb292702fadb781b1251e07
... it is an abbreviation of "Solar Version".
Since nobody can remember that:
remove OUTDIR OUTDIR_FOR_BUILD SOLARVER SOLARVERSION solarpath
and any mention thereof.
Change-Id: Idb3031c4f25a76ac05b22ec67e3ca3e1e8e512ad
Reviewed-on: https://gerrit.libreoffice.org/6515
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
This is both an optimisation and a cleanup.
This converts code like
aStr.indexOf("XX") == 0
to
aStr.startsWith("XX")
and converts code like
aStr.lastIndexOf("XXX") == aStr.getLength() - 3
to
aStr.endsWith("XXX")
Note that in general
aStr.lastIndexOf("X") == aStr.getLength() - 1
converts to
aStr.isEmpty() || aStr.endsWith("X")
so I used the surrounding context to determine if aStr could be empty
when modifying the code.
Change-Id: I22cb8ca7c2a4d0288b001f72adb27fd63af87669
- stop copying the DLL to OUTDIR
- since that was the main reason for the separation between
CliUnoApi and CliUnoApiTarget, merge the targets;
the newly inherited variables are not expected to cause problems
- hardcode target to URE bin dir for now, no immediate need for
multiple layers
Change-Id: I428d801ec7058e1c6374d8162a4118a3fe581978
to cppu::supportsService
Change-Id: I0b03d3910f094f2183bf9859db9d5bcaf35d1f14
Reviewed-on: https://gerrit.libreoffice.org/6370
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Refactor everything to find and link libraries directly in INSTDIR.
- add gb_LinkTarget_get_linksearchpath_for_layer, and use it to set up
-L paths for T_LDFLAGS in such a way that only allowed libraries
can be linked against; i.e. it's not possible to link URE
linktargets against OOO or not-installed libraries
- gb_Library_get_target is now same as the gb_LinkTarget_get_target
(TODO: this needs cleanup)
- since a pattern rule won't work for linking libraries in INSTDIR,
add a separate per-file rule for every INSTDIR lib
- pattern rule can't find link target in the clean target any more
so add a LINKTARGET variable
- disable gb_Library_add_auxtarget, no auxtargets need to be copied
- tweak the call to gb_Library_Library_platform to pass in a path
in sdk/lib for the versioned URE libs
- fix the Library clean target
- add LAYER parameter to gb_LinkTarget_LinkTarget
- adjust platform link commands
- MSVC link command now uses explicit -manifestfile and -pdb
parameters to keep misc. files out of INSTDIR
- remove gb_Helper_OUTDIR_FOR_BUILDLIBDIR
- adjust Extension, CppunitTest, JunitTest, PythonTest, Gallery,
various CustomTargets to search INSTDIR
- remove SDK library symlinks and import libs from odk/Package_lib
- on Mac OS X, put .dylib symlinks into sdk/lib even though those
are not packaged and would be created by the SDK configury;
we need these to be somewhere for linking anyway
- add a (unfortunately cyclic) dependency on Package ure_install to sal
Change-Id: I70d88742f8c8232ad7b9521416275c67b64fe6cf
...via unoidl-write and the new source-format registry provicers, instead of
using idlc to produce .urd files, regmerge to merge them into legacy .rdb files,
and unoidl-write to translate those to new UNOIDL .rdb files.
gb_UnoApi and gb_InternalUnoApi ctors take an additional argument now that is
the path (below $(SRCDIR)) of the source-format registry from which to obtain
UNOIDL entity definitions. It can either be an .idl file (in which case no
*_add_idlfiles calls should be used and the resulting .rdb will contain all the
entities from that one .idl file; used in some tests to conveniently define all
test-specific entities in a single file) or a directory denoting the root of an
.idl file tree (in which case *_add_idlfiles calls specify the entites to
include in the resulting .idl file). (In the first case, the generated .rdb
file needs to depend on that single .idl file, so the gb_UnoApiTarget ctor
contains a dependency on that additional argument, which happens, as a side
effect, to trigger rebuilds in the second, tree-based case when addition/removal
of .idl files in the tree causes updates of directory time-stamps.)
UnoApiPartTarget and all the dependency-tracking logic based on .urd files in
solenv/gbuild/UnoApiTarget.mk is gone. Generation of an .rdb file now depends
on its source registry (see previous paragraph) and all the .idl files specified
with *_add_idlfiles (in the second, tree-based case above).
A consequence of that is that gb_UnoApi_add_idlfile, -_nohdl, and -_noheader all
do the same now. I left them in for now anyway, maybe they become relevant
again when the use of cppumaker is changed to read directly from a source-format
registry instead of going via a .rdb registry.
The legacy tools idlc, regcompare, regmerge, and regview are still contained in
the URE or SDK for now.
cb344cd59e1ddb7c6db66dbd9263b4755969d4ba "Revert 'Looks like idlc resolved
typedefs inside sequence<...>'" is re-reverted as now "the current offapi.rdb is
generated via unoidl-write instead of idlc."
Change-Id: I3d9d92f17326bc9f49dd934c85aab6a17951d06d
...the "double use of udkapi.rdb in climaker call in
testtools/CustomTarget_bridgetest_climaker.mk looked fishy" indeed.
Everything built in module testtools that is not used by the "native inprocess"
test case (testtools/CustomTarget_uno_test.mk) is more-or-less faithfully copied
over from pre-gbuild times, but the code to actually (manually) execute it is
effectively lost: bridgetest_client against bridgetest_server and
bridgetest_javaserver; bridgetest_inprocess_java; cli_bridgetest_inprocess.exe.
So this cli_types_bridgetest.dll is effectively dead code today, but at least it
is a more faithful copy of the pre-gbuild version again.
Change-Id: If01a9d837dc6bf3837a17878d8a4bfaf87ab6d4d
...also, the use of double use of udkapi.rdb in climaker call in
testtools/CustomTarget_bridgetest_climaker.mk looked fishy.
Change-Id: I8be22b184740d65e567df65bae51fe18066be102
What is a little confusing is that the udkapi.rdb ends up as types.rdb in the
installation set (in the URE's sub-tree). So all places that reference it
during the build do so as "udkapi" while all places that reference it in an
installation set do so as "types."
Change-Id: I35d0695966b3bd703f5494b636b9782efc0d3fcb
(The "statistic" target in offapi/UnoApiMerge_types.mk appears to have been
dead code already for quite a while.)
Change-Id: I0852ebf1f765ba881abb6ce4db496e949076fc64
