summaryrefslogtreecommitdiff
path: root/linguistic
diff options
context:
space:
mode:
authorNoel Grandin <noel.grandin@collabora.co.uk>2018-11-22 08:57:37 +0200
committerNoel Grandin <noel.grandin@collabora.co.uk>2018-11-23 20:31:22 +0100
commit49b1107b6ea81c32628a52202ffbbcd44b042e38 (patch)
treea2267ae3fe189cc6cd88d2e0c972842e97ea3d7a /linguistic
parentc110bfc810ed381409d0f3742d8ce58a690d840f (diff)
remove unused enums in reportdesign,linguistic,l10ntools,vcl,svx
Change-Id: I3ae854f9fed485be915ded5bc4d7e93f5db23dc6 Reviewed-on: https://gerrit.libreoffice.org/63891 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Diffstat (limited to 'linguistic')
-rw-r--r--linguistic/source/defs.hxx2
1 files changed, 0 insertions, 2 deletions
diff --git a/linguistic/source/defs.hxx b/linguistic/source/defs.hxx
index c39740e01d65..38909e82362c 100644
--- a/linguistic/source/defs.hxx
+++ b/linguistic/source/defs.hxx
@@ -82,8 +82,6 @@ struct LangSvcEntries_Thes : public LangSvcEntries
class LinguDispatcher
{
public:
- enum DspType { DSP_SPELL, DSP_HYPH, DSP_THES, DSP_GRAMMAR };
-
virtual void SetServiceList( const css::lang::Locale &rLocale, const css::uno::Sequence< OUString > &rSvcImplNames ) = 0;
virtual css::uno::Sequence< OUString > GetServiceList( const css::lang::Locale &rLocale ) const = 0;
generated by cgit (git 2.34.1) at 2024-07-06 15:30:06 +0000
r class='nohover-highlight'> Both MSVC and Clang (with -building-pch-with-obj) generate one extra object file for code from the PCH, saving repeated generating of this code for every object using the PCH. This causes problems when temporarily disabling PCH by doing 'make ENABLE_PCH=' (e.g. when checking #include's are correct), as this object would no longer be linked in, and objects not rebuilt with PCH disabled would still need it. This patch allows doing 'make BLOCK_PCH=1' instead, which will disable PCH with the exception of this object file still getting linked in. Change-Id: I8fcb150ef27ebb34118d62739a1a1558aa1a6f3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88341 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2020-01-18add support for Clang's -building-pch-with-objLuboš Luňák This marks the PCH as having an accompanying object file, and this object file needs to be also built, but this allows the compiler to skip generating stuff that'd be shared by all the objects using the PCH. Currently it doesn't make much of a difference, few symbols if any, but template instantiations could be shared this way, as soon as Clang gets the necessary support (my WIP patch). Change-Id: Ib1b86338d85a47b48979558435253dc2672a0da8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87009 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-12-07Remove redundant gb_YACC indirectionStephan Bergmann (as discussed at 0a803c0a41f46be4019ddd2768b4be5669b7ab59 "Honor BISON passed into configure") Change-Id: I160a3c97414be47cd1efef0b7fac4af93a398ac6 Reviewed-on: https://gerrit.libreoffice.org/84684 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-12-06Honor BISON passed into configureStephan Bergmann ...and require new-enough Bison for --enable-compiler-plugins to not generate bogus loplugin:external warnings in Bison boilerplate code. (As happend for me on macOS where /usr/bin/bison is version 2.3. Not sure which versions exactly are too old, but at least 3.4.1 is known good. If other versions newer than 2.3 turn out to be problematic too, the configure.ac check will need to be adapted.) No idea why there need to be three places across solenv/gbuild/ that set gb_YACC (to the same bison in each case), but leave that to be cleaned up later. Change-Id: I01d8219726f8df7895631b817866207327367759 Reviewed-on: https://gerrit.libreoffice.org/84650 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-10-14fix incorrect gb_DISABLE_PCH_REUSE testLuboš Luňák Change-Id: Ife41ea7ad19c03b8dca6afe8b15d0f3b752b533b Reviewed-on: https://gerrit.libreoffice.org/80789 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-10-04add gbuild function for a common PCH and use it in sc/ and sax/Luboš Luňák And make it simple to disable the whole feature by setting gb_DISABLE_PCH_REUSE=1, just in case. Also work around a possible BOOST_ALL_NO_LIB mismatch when using the common PCH. Change-Id: I96fd507edf1ada6242ac225026250e5a588d0193 Reviewed-on: https://gerrit.libreoffice.org/79365 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-10-04support reusing PCH if linktarget has additional reasonable definesLuboš Luňák Where reasonable means they are from a list of defines known not to affect the system headers, and so they are safe to differ from how the PCH was built. A bit hackish, but works in practice. Change-Id: Ia00d2e4c56212aca05ba9d47abbb0d253998219f Reviewed-on: https://gerrit.libreoffice.org/79364 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-10-04add gb_LinkTarget_reuse_precompiled_headerLuboš Luňák Similar to gb_LinkTarget_set_precompiled_header, but uses PCH created by another linktarget. This allows using a PCH even for linktargets that are small and creating their own dedicated PCHs is not worth it. The ultimate goal is having some default PCH that will be used if no explicit PCH is set. Change-Id: I4d72acdba7181bb5c7c1cdead776f548be36ba33 Reviewed-on: https://gerrit.libreoffice.org/79362 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-10-04do not abort build on PCH CXXFLAGS mismatch if set explicitlyLuboš Luňák All the various gb_CppunitTest_add_cxxobjects variants actually allow passing additional CXXFLAGS. However, currently that would abort the build if PCH is used, because PCH requires the same CXXFLAGS. But if those extra CXXFLAGS are set explicitly, just skip using the PCH for that one file, as the mismatch is intentional. Change-Id: Iec4eed6d5f94c3e97ee461241203a84d21e8113c Reviewed-on: https://gerrit.libreoffice.org/80120 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-10-04always use gb_LinkTarget__get_cxxflags for cxxobjectsLuboš Luňák E.g. gb_LinkTarget_add_exception_object adds it explicitly, but gb_LinkTarget_add_cxxobject itself does not, even though other variants (c,objc,objcxx) do it. This means that when compiling tools/qa/cppunit/test_cpuid.cxx it doesn't get the correct -O/-g flags, because CppunitTest_tools_test.mk uses gb_CppunitTest_add_cxxobjects to add $(INTRINSICS_CXXFLAGS). And that in its own actually should use the add_exception_objects variant, it didn't presumably because that one used to have cxxflags passing broken until I fixed it in 4bbdab901eb3c7d32d28910fb830f4b0422eee91. The usage in Library_cpp_uno.mk even explicitly works around the lack of debug symbols. Change-Id: Idc794e95bb817cd2ba2942b8e1f04f80d6722f97 Reviewed-on: https://gerrit.libreoffice.org/80119 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-09-23the PCH timestamp is actually LinkTarget's, not PCH'sLuboš Luňák Because the timestamp says that the LinkTarget's PCH dependencies are ready. Change-Id: I5c9b965bf6d5a62b16972d5b0ea84a97f771e14f Reviewed-on: https://gerrit.libreoffice.org/79361 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-09-23remove unused gbuild codeLuboš Luňák gb_CxxObject__set_pchflags just sets a variable, which is not used here. It should have been removed in 66a0713dc9c676182fcd7aa1e21f8dc25c05be5e, but even back then the removed function didn't depend on it, so this should have been removed even sooner. Change-Id: I629d6337d0aa4066bd3141b22aed84dfeeac5b7f Reviewed-on: https://gerrit.libreoffice.org/79315 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-09-23do not require $(SRCDIR) in every gb_Library_set_precompiled_headerLuboš Luňák Change-Id: I7b3a22584bb2e4d501f509ffcd80929feed23a4c Reviewed-on: https://gerrit.libreoffice.org/79360 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-09-02Add -latomic to the end of Linux C++ linker command linesStephan Bergmann b11763dbaa0c7f427ea47abe9b98995cb49a8595 "link with -latomic on mips(el), armel, powerpc, m68k" had added -latomic to the linker command lines of just some Linux platforms (which apparently happened to actually require it). But there were three issues with that: * The -latomic came too early on the command line, so that it wasn't used to satisfy dependencies of .o files that came later. See the discussion at <https://gerrit.libreoffice.org/#/c/78319/> "set -Wl,--no-as-needed for -latomic". * There is presumably no need to include -latomic on C linker command lines. * <https://gcc.gnu.org/onlinedocs/gcc-7.3.0/libstdc++/manual/manual/using.html #manual.intro.using.flags> (matching our Linux libstdc++ 7.3.0 baseline as per README.md) states: "Linking to libatomic is required for some uses of ISO C++11 <atomic>." So we should better include -latomic on every Linux C++ linker command line that uses libstdc++. (This patch assumes that we always use libstdc++ on Linux.) Ideally we could rely on -latomic always being available with our baseline libstdc++ 7.3.0, but when using Red Hat Developer Toolset 7 that appears not to be the case, as reported by a Jenkins build for an older version of this change (see below), so use ATOMIC_LIB from the preceding commit <https://gerrit.libreoffice.org/#/c/78336/> "add -latomic configure check...". <https://ci.libreoffice.org/job/gerrit_linux_gcc_release/40298/console>: > [build LNK] Executable/unoapploader > /opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: cannot find -latomic > collect2: error: ld returned 1 exit status > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/solenv/gbuild/LinkTarget.mk:636: recipe for target '/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/LinkTarget/Executable/idxdict' failed This patch adds -latomic only on Linux. Similar changes can be made for other platforms if need be. Change-Id: I75df5410677f4c31c796d7ba85532bcdb47eb111 Reviewed-on: https://gerrit.libreoffice.org/78380 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>