summaryrefslogtreecommitdiff
path: root/solenv/gbuild/LinkTarget.mk
AgeCommit message (Collapse)Author
2020-04-21CLANG_C -> CLANG_CCLuboš Luňák
Change-Id: I50ed05116df3f295af6406f0ee45610d9e1e031e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92619 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-20prefer building Skia with Clang if possible (tdf#131697)Luboš Luňák
I.e. try to find and use Clang even if the default compiler is something else. Skia is optimized to be built with Clang(-cl) and in CPU-based raster mode some operations are several times slower if built with something else (e.g. fmax/fmin do not get optimized to inline assembly). It is enough to select Clang to be installed in the MSVS installer. At this point it unclear how to handle release binaries, if it should work this way and enforced, or maybe Clang could be used for building everything, or maybe some other way. Change-Id: I6b95a0f2d5cbf176942d9e01136990b14be6dba8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92415 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-06use full path for the PCH .hxx file for MSCLuboš Luňák
Microsoft cl.exe actually doesn't care, but clang-cl without this complains that it cannot find the .hxx file for the PCH. Change-Id: Ic2db94f2323ddb884ea71e6ac6554cc0a5ab682a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91744 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-25fix --enable-mergedlibs buildNoel Grandin
after my recent additions to the list of libs exceeded Windows command line length limit (mostly affecting those people whose workspace was under a fairly long folder name) Change-Id: I4d60e9704db49f0a3f562200b737879fba7ee5a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-19add --enable-optimized=debugLuboš Luňák
This will use -Og with GCC/Clang instead of -O0, which should make unittests run faster without (hopefully) breaking anything related to debugging. This is primarily meant to Jenkins builds, where debug info is rarely needed (backtraces for unittest crashes AFAICT). This can be also used to make LO itself run faster when developing, but I personally do not find it worth it (with Clang and full PCH this makes starmath build take about 70% longer, although presumably for non-PCH builds the relative increase will be smaller). Change-Id: I198d0759ebca94c90be662e02e0f1281a24d1d70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88917 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-10add BLOCK_PCH to gbuild, allowing partial non-PCH rebuildsLuboš Luňák
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>
2019-05-27abort if PCH cannot be used because of CXXFLAGS mismatchLuboš Luňák
Those should mean an error somewhere, e.g. as in the recent libcmis fix. Change-Id: Iecb973a8f1d56a1bfa0a0e8a5c923e5598682b94 Reviewed-on: https://gerrit.libreoffice.org/73029 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Tested-by: Jenkins
2019-05-24disable warnings in external libsLuboš Luňák
As in, really disable, so that they do not even show. This moreover avoids tons of D9025 warnings from MSVC about overriding -W4 with -w. Change-Id: Ia2e72fd72d883d91bdd89e467ee42f259e2ae033 Reviewed-on: https://gerrit.libreoffice.org/72899 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-05-17Make spsupp_x64 independent of shell/CustomTarget_x64Mike Kaganski
... in preparation for further changes. Thanks to Noel Grandin for the hint! Change-Id: I2b223322d1d42099b56a74a92e3c39631d6b581c Reviewed-on: https://gerrit.libreoffice.org/72470 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-05-09support different levels of PCH usageLuboš Luňák
There are now 4 levels of PCH support, the previous 'full' level adding to PCH whatever the update_pch script finds useful, and new levels 'system', which adds only external headers, 'base', which is 'system' and LO basic headers (sal, osl, rtl, vcl) and 'normal', which is 'full' without headers from the module built itself. With Clang/GCC even 'system' still saves some time (10-15%) and since external headers should rarely if even change, it should be without most of the disadvantages of PCH. And even 'base' should be pretty easy to use, as those headers should be rarely changed while developing, thus avoiding the need for massive rebuilds. Using 'normal' or 'full' does not seem to be worth it with Clang or GCC, but with MSVC that still makes a difference, so keep(?) 'full' the default there. The update_pch script unfortunately does not include as many system headers as it could, since it includes only what is directly included by the .cxx, but not what's included indirectly by .hxx files. https://lists.freedesktop.org/archives/libreoffice/2019-May/082685.html Change-Id: If83a07a1fc9b77d0134502b0d89348944f82806b Reviewed-on: https://gerrit.libreoffice.org/71580 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-04-13Pass to linker its debuginfo options, not compiler'sMike Kaganski
... follow-up to commits 65f27f55cbb5994fbabe9716a92ea4d3f20e3e54 and eeeec33ada5923f1f534334b22c15d6e2c6f1d35 Otherwise, e.g. on Windows, linker complains about unknown options /FS and /Zi, and doesn't link debug info, making debug build useless. Change-Id: I256a463b4b4e4bb339c94a393c9b1d17e85b7a3f Reviewed-on: https://gerrit.libreoffice.org/70713 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-04-11fix getting correct debug/nodebug PCH file with selective debuginfoLuboš Luňák
Since debuginfo enabled/disabled is per-linktarget, the rules need to be per-linktarget as well, and so instead of one generic rule there needs to be a define generating one rule per each linktarget. Change-Id: I9423c4a86bc02aa3c0bf816f47e3c3d43ff03b23 Reviewed-on: https://gerrit.libreoffice.org/70370 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-04-11merge --enable-selective-debuginfo into --enable-symbolsLuboš Luňák
This got broken again due to confusion about the interaction between the various debug/symbol/whatever variables, so let's try to clean it up once more. So gb_SYMBOLS or any other global flag is no more. For checking whether a build target should get symbols, use gb_LinkTarget__symbols_enabled, which is internally controlled by gb_ENABLE_SYMBOLS_FOR (and flags from configure, command line or wherever affect that). This commit breaks the debug/nodebug split for PCH files, but fixing that is a relatively separate and complex change, so it'll be done in another commit. Change-Id: I6060dd38684445bb761e664344fb530386481332 Reviewed-on: https://gerrit.libreoffice.org/70369 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-04-11fix some gb_LinkTarget functions with linktargetmakefilename argumentLuboš Luňák
The gb_Library__forward_to_Linktarget etc. functions always pass linktargetmakefilename as argument $(4). Change-Id: If21de5bc44c9f952386b4795b0d46ea4a7b53714 Reviewed-on: https://gerrit.libreoffice.org/70389 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-04-11--gdb-index flags should be used only when linking with symbolsLuboš Luňák
Change-Id: I32681fd56367c583efc55ab11c0bc59aaf845b86 Reviewed-on: https://gerrit.libreoffice.org/70367 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-04-07pass all arguments to gb_LinkTarget_add_cxxobject properlyLuboš Luňák
Change-Id: Ie7469f32f08c7acf5a972dec12fa75604aa8336d Reviewed-on: https://gerrit.libreoffice.org/70368 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann
...which was at maximum set to GCC's -finline-limit=0 -fno-inline (solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug builds "since forever", but that looks very much like cargo cult: -fno-inline "is the default when not optimizing" anyway (<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline (and maybe was present for ancient compilers that only supported -finline-limit but not -fno-inline?). Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874 Reviewed-on: https://gerrit.libreoffice.org/66836 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-23Drop use of obsolete GCC -fno-default-inlineStephan Bergmann
...that is documented as: "Does nothing. Preserved for backward compatibility." ever since <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=160384> from 2010. -fno-default-inline was the only value ever set in gb_DEBUG_CXXFLAGS, so the latter can be removed now. The use of gb_DEBUG_CXXFLAGS had accidentally already been removed from gb_LinkTarget__get_debugcxxflags with e751e24250fda31dde52b3c65ca79f86142dc789 "--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutil", and that leaves gb_LinkTarget__get_debugcflags and gb_LinkTarget__get_debugcxxflags with identical definitions, so replace those two with a single gb_LinkTarget__get_debugflags. Some external modules had used only gb_DEBUG_CXXFLAGS, when this was apparently meant to be used in addition to gb_DEBUG_CFLAGS, so those uses have been changed to gb_DEBUG_CFLAGS now. Change-Id: I84ea0ab1233569b0b02ca057240a71f138352381 Reviewed-on: https://gerrit.libreoffice.org/66808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-29tdf#114635: reimplement TWAIN-based scan using 32-bit shim on WindowsMike Kaganski
Since TWAIN is only actually available as 32-bit component on Windows, to use it in a 64-bit program, we need a 32-bit shim program that does all actual communication with TWAIN subsystem. This change reimplements TWAIN implementation to be a separate 32-bit process. Image is transfered from the shim to main program using file mapping API. This reverts most of commit 585d9806961342e95f7318fb947bd31e9f86dee0. 64-bit LibreOffice doesn't bundle TWAIN DSM library now. TWAIN DSM source code is still used for TWAIN headers. Change-Id: I46f178ad36acd97a9eff156624b99036fcbb83f8 Reviewed-on: https://gerrit.libreoffice.org/65688 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-11-01gbuild: rename value OS=IOS to OS=iOSMichael Stahl
This gets rid of the horrible hack in gbuild.mk to accomodate the case-incorrect iOS platform makefiles that cannot be renamed without upsetting git on file systems that sadly lack the case sensitivity feature. Keep the macro defined to IOS though. Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234 Reviewed-on: https://gerrit.libreoffice.org/62705 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2018-07-04add --enable-split-debug for -gsplit-dwarfLuboš Luňák
https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html Change-Id: I2a02e23e46d7a54083249408f09fba87932b1d44 Reviewed-on: https://gerrit.libreoffice.org/56416 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2017-11-24tdf#113787: gbuild: fix the version of cli_cppuhelper assemblyMichael Stahl
There is one usage of gb_Library_add_generated_cxxclrobjects in the entire repo, and regrettably generated C++/CLR objects weren't actually implemented in the new build system, so the assembly.cxx with its generated version number was simply ignored.
2017-10-28Work around "xargs: environment is too large for exec" errors on WindowsStephan Bergmann
...when e.g. doing 'make sal.clean' Change-Id: I63c13dd010cf8d24f9548cf2fe089067381a4efe Reviewed-on: https://gerrit.libreoffice.org/43948 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-07-21migrate to boost::gettextCaolán McNamara
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string") * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching MODULE .mo files * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui goes from l10n target to normal one, so the res/lang.zips of UI files go away * translation via Translation::get(hrc-define-key, imbued-std::locale) * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there to keep finding the .hrc file uniform) so magic numbers can go away there * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation mechanism * en-US res files go away, their strings are now the .hrc keys in the source code * remaining .res files are replaced by .mo files * in .res/.ui-lang-zip files, the old scheme missing translations of strings results in inserting the english original so something can be found, now the standard fallback of using the english original from the source key is used, so partial translations shrink dramatically in size * extract .hrc strings with hrcex which backs onto xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap * extract .ui strings with uiex which backs onto xgettext --add-comments --no-wrap * qtz for gettext translations is generated at runtime as ascii-ified crc32 of content + "|" + msgid * [API CHANGE] remove deprecated binary .res resouce loader related uno apis com::sun::star::resource::OfficeResourceLoader com::sun::star::resource::XResourceBundleLoader com::sun::star::resource::XResourceBundle when translating strings via uno apis com.sun.star.resource.StringResourceWithLocation can continue to be used Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
2017-06-22--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutilStephan Bergmann
Change-Id: I277f30129560ea9fa76d6439a60bb191358df99d Reviewed-on: https://gerrit.libreoffice.org/39088 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-06-19only unit-test one loplugin at a timeNoel Grandin
tell the plugin code when we are unit-testing it, so we can suppress all the warnings except for the plugin we are currently testing Change-Id: I240c8e37eba90c219e53c29531a3a43bc841a1c8
2017-06-07Remove gb_LinkTarget_add_generated_cxxobjectsStephan Bergmann
...in favor of gb_LinkTarget_add_generated_exception_objects. The former would have needed any flags to be passed in explicitly (but no call sites did), so e.g. StaticLibrary_graphite didn't have any debug information (when building with --enable-debug). I guess there is no downside to having C++ exception support enabled in these places, and using _add_generated_cxxobjects instead was likely an oversight in the first place (at least in the case of external/graphite/StaticLibrary_graphite.mk, it was that way ever since 1ceb47d96da9e7977c96241f49ad291ff0466970 "graphite: convert to gbuild", but for no apparent reason). Change-Id: I9986a6c5ec30a521095dbe5315e5ca649741a790
2017-02-21When building with clang-cl on Windows, build CLR code with MSVCStephan Bergmann
...as clang-cl doesn't support the /clr switch. * In configure.ac, capture the MSCV version (that would be used if CC hadn't been overridden to use clang-cl) into MSVC_CXX. * The logic which flags to pass into gb_CObject__command_pattern is coded into the platform-agnostic LinkTarget.mk, so it's too late to try and filter all relevant flags in com_GCC_class.mk, depending on whether a given .cxx file is a normal one built with the normal $CXX or a special /clr one built with $MSVC_CXX. Thus, a new CxxClrObject class had to be introduced that captures this information early. * When building with clang-cl, the generated config_host/config_*.h files contain values suitable for clang-cl, but not for MSVC. But the .cxx files compiled with MSVC happen to include config_global.h, and would fail. Hack around that problem for now by introducing a hard-coded, minimal solenv/clang-cl/config_global.h that is found first when buliding such a CxxClrObject. Needs cleaning-up properly. Change-Id: Iff8aac51c0b4fa906b14503c692640dda0996d33 Reviewed-on: https://gerrit.libreoffice.org/34509 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-27Make plugin rewriting work on Windows tooStephan Bergmann
...in a somewhat hacked-up way for now (see the TODO comment) Change-Id: Ida89fb8257b876cfca05b3048ce15996091c5703
2017-01-27Use 'CPT' (for "compilerplugins test") instead of 'C??'Tor Lillqvist
Change-Id: I783a121b43223bbd0fd3f6250b2e009a77c87a85
2016-11-17Have a specific TARGETTYPE for CompilerTest after allStephan Bergmann
...instead of leaving it empty. (645583dfd374c8b02f3c0eeba6233a0bb5884d68 "New compilerplugins/clang unit tests": "Checking the input files is implicitly phony, as the compilation step doesn't generate any object files, and the link step does nothing because there is no gb_LinkTarget_set_targettype for CompilerTest.") In preparation for using compilerplugins/clang with clang-cl on Windows. Change-Id: Ica4f16a4b249537f78ce21fcbe7c4afea8214821
2016-11-15New compilerplugins/clang unit testsStephan Bergmann
...to check that loplugin produces warnings/errors as expected: * Clang has a -verify switch that makes it easy to write test input .cxx files that list in comments all the warnings/errors that are expected, and let Clang check those expectations instead of generating object code. See include/clang/Frontend/VerifyDiagnosticConsumer.h in the Clang source tree for documentation. * Introduce a CompilerTest gbuild class that uses the existing LinkTarget class as much as possible. Checking the input files is implicitly phony, as the compilation step doesn't generate any object files, and the link step does nothing because there is no gb_LinkTarget_set_targettype for CompilerTest. The setup at least works for Clang on Linux (will need adaptions for Clang on Windows; compilers other than Clang are not relevant for now given this is used to check compilerplugins). * Definition of gb_CFLAGS_WERROR in solenv/gbuild/platform/com_GCC_defs.mk needs to be lazy ('=' vs. ':=') so that CompilerTest can override it: The Clang -verify mode wants the input files to specify whether the loplugin diagnostics are warnings or errros, so they consistently need to be errors independent of --enable-werror configuration. * A first (example) test is in compilerplugins/clang/test/salbool.cxx. The corresponding gbuild CompilerTest instance is in solenv/CompilerTest_compilerplugins_clang.mk for now. The reason for that odd split across compilerplugins/ and solenv/ is that there is no compilerplugins/Modules_compilerplugins.mk file, so this setup is the easiest hack for now (to be cleaned up). (Another area that could be improved is that all test files need to be listed explicitly in the CompilerTest_*.mk file, instead of, say, using all .c/.cxx/.m/.mm files in a specified directory.) * The test is run somewhat late during a top-level 'make', after loplugin has already been used in compilation. But it can be run manually (e.g., 'make solenv') when making changes to loplugin during development. Change-Id: I01e12fb84887d264ac03ef2484807458c2075af4
2016-07-11Make --enable-symbols orthogonal to --enable-debug/-dbgutilStephan Bergmann
Change-Id: I523bc1d848e40489370eefe00046e0a257ed2505 Reviewed-on: https://gerrit.libreoffice.org/27058 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-07-11Break gb_DEBUGINFO_FLAGS out of gb_DEBUG_CFLAGSStephan Bergmann
...in preparation of making them orthogonal Change-Id: If75b334c954138b3aed4f8d1ac33061a2267ad52 Reviewed-on: https://gerrit.libreoffice.org/27056 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-07-11Centralize setting gb_DEBUGINFO_FLAGS for gb_SYMBOL in LinkTarget.mkStephan Bergmann
Change-Id: Ie8ca63d48f66833a778342af8fbe19006fb6f143 Reviewed-on: https://gerrit.libreoffice.org/27055 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-04-26Enable Clang plugin warnings in Bison source codeStephan Bergmann
-Werror is generally suppressed in Bison-generated C/C++ code (as in all other generated code) to silence warnings from the Bison skeleton code. And the Clang plugins suppress warnings in generated WORKDIR code based on the presumed source location (i.e., taking #line directives into account). So introduce a new PLUGIN_WARNINGS_AS_ERRORS mode where warnings from Clang plugins are reported as errors even if -Werror is suppressed. That way, any warnings in the Bison skeleton code still do not lead to compilation errors, while (at least plugin- emitted) warnings in the genuine source code do. Unfortunately this cannot also be enabled for Flex source code, as at least Flex 2.5.39 generates poor code that does not properly prefix all skeleton code with appropriate #line directives, so that some skeleton code would be mistaken for genunie source code, and compilation would fail due to errors. Also, %glr-parser Bison input appears to generate no #line directives at all (at least with Bison 3.0.4), so all of connectivity/source/parse/sqlbison.y is considered generated code and plugin warnings are still suppressed throughout. Change-Id: Id746e81cbfa5f77628b0a34c7b82780948e7db08
generated by cgit (git 2.34.1) at 2025-02-12 00:12:26 +0000