summaryrefslogtreecommitdiff
path: root/solenv/gbuild
AgeCommit message (Collapse)Author
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-14add some more libs to libmergedNoel Grandin
Change-Id: I9e1677c26cf082ed78765995bfa7f57ff50f8e7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88580 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-12add some more libs to libmergedNoel Grandin
Change-Id: I2d3c3d64f1fb1d3635bdde761f6502ba05221f95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88522 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-12add some more libs to libmergedNoel Grandin
Change-Id: I14ec1c6015c8a71fabca90ca3dec52965915a63f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88511 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-11Fix duplicate "stringresource" in MERGE_LIBRARY_LISTStephan Bergmann
...where both entries were added with 40fe721462df5bedacddc8829cefc3d739cf940f "add some more libs to libmerged", and defining Library_stringresource in scripting/Module_scripting.mk is conditional on BUILD_TYPE SCRIPTING. This will hopefully fix <https://ci.libreoffice.org/job/lo_callgrind_linux/7884/> (which apparently uses --enable-mergelibs), > /usr/bin/ld: /home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/workdir/CxxObject/scripting/source/stringresource/stringresource.o: in function `stringresource::StringResourceImpl::isReadOnly()': > /home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/scripting/source/stringresource/stringresource.cxx:297: multiple definition of `stringresource::StringResourceImpl::isReadOnly()'; /home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/workdir/CxxObject/scripting/source/stringresource/stringresource.o:/home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/scripting/source/stringresource/stringresource.cxx:297: first defined here > /usr/bin/ld: /home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/workdir/CxxObject/scripting/source/stringresource/stringresource.o: in function `stringresource::StringResourceImpl::loadLocale(stringresource::LocaleItem*)': > /home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/scripting/source/stringresource/stringresource.cxx:659: multiple definition of `stringresource::StringResourceImpl::loadLocale(stringresource::LocaleItem*)'; /home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/workdir/CxxObject/scripting/source/stringresource/stringresource.o:/home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/scripting/source/stringresource/stringresource.cxx:659: first defined here [...] Change-Id: Ie667487bced048d3b0b0081a9fa4abafa090f02b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88468 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Jenkins
2020-02-11add some more libs to libmergedNoel Grandin
and fix a consequent symbol name clash in basctl Change-Id: Idc836fcbb379e1046a60008391635eb6241b27c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88188 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-10ignore -DGLM_FORCE_CTOR_INIT for shared PCHLuboš Luňák
It's not used by the PCH, so it's safe. Change-Id: Ia86bf0ff31bc40b81b10517f8abd33e9170dba2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88362 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-02-06gb_CppunitTest__use_java_ure can be private againStephan Bergmann
...(which it already was until 1f6e670605cc856a6e9febb024f9cb2427156020 "gbuild: require java UNO runtime explicitly"), as 2a87b3b5aed8296a7506374fd5324c5659a88cb5 made that implicitly called from gb_CppunitTest_use_jar(s), so its (sole outside) use in postprocess/CppunitTest_services.mk is redundant Change-Id: I9928521d184c54688de134ff3b9b5743ba3509c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88134 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-06Missing test dependencyStephan Bergmann
...for CppunitTest that use Java, like CppunitTest_dbaccess_hsqldb_test failing with something like > warn:jfw:2880195:2880195:jvmfwk/source/fwkbase.cxx:94: [Java framework] A vendor settings file was not specified.Check the bootstrap parameter UNO_JAVA_JFW_VENDOR_SETTINGS. > warn:jfw:2880195:2880195:jvmfwk/source/framework.cxx:582: [Java framework] A vendor settings file was not specified.Check the bootstrap parameter UNO_JAVA_JFW_VENDOR_SETTINGS. because the jvmfwk3 ini file is missing from instdir. (Should those tests also set UNO_JAVA_JFW_ENV_JREHOME=true, as is done in unotest/source/cpp/officeconnection.cxx and unotest/source/java/org/openoffice/test/OfficeConnection.java?) Change-Id: Iabf1198246c17410e71d5b85454662ff85a7b478 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88112 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-06No more need to add unoil.jar to URE_MORE_JAVA_TYPESStephan Bergmann
...after ae855bf48163ff64d94cfc34aff8e37abdb5518d "tdf#117331 Merge jurt and unoil into ridl" Change-Id: Idf640b8c3bb9d8a19e26d494498b9902a75f4e64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88053 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-06Fix typo in call to gb_CppunitTest_use_java_ureStephan Bergmann
...which had been renamed from gb_CppunitTest__use_java_ure in 1f6e670605cc856a6e9febb024f9cb2427156020 "gbuild: require java UNO runtime explicitly", apparently forgetting to adapt this use Change-Id: Ia093fcf2a5728247c259e549722329ade7b60931 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88052 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-06Nothing should link against unoil.jar any moreStephan Bergmann
...after ae855bf48163ff64d94cfc34aff8e37abdb5518d "tdf#117331 Merge jurt and unoil into ridl", so no need any longer to filter it out of the classpath here Change-Id: Ifb01de5d9efa7ed264824030ad0e1333ab8b43ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88054 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-04tdf#117331 Merge jurt and unoil into ridlSamuel Mehrbrodt
jurt.jar and unoil.jar are kept as effectively empty jars, each with a Class-Path: ridl.jar in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or without also loading ridl.jar) will still have access to their content. Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi) are not part of the URE, but are now made available by URE's ridl.jar. This should probably not cause problems in practice. At least for now, we seal exactly those packages in ridl.jar that were originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now, but that would be mildly incompatible, as it would prevent 3rd-party code from introducing additional UNOIDL entities in the relevant namespaces (even if that is something we do not want 3rd-party code to do anyway). However, some JunitTest_jurt_* define classes in those sealed packages. In the past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt. Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets leave that for a follow-up clean up.) As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/. Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a Co-authored-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-03Optionally generate PDBs also for C#Juergen Funk
Enables pdb generation for symbol builds, for: - cli_basetypes.dll - cli_cppuhelper.dll - cli_uno.dll - cli_ure.dll Not covered are: - cli_oootypes.dll - cli_uretypes.dll ..as sadly climaker generates those, and can't produce PDBs. Change-Id: I6004e06f9f2a76b4577ad9a4de971f46ad6bf521 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87727 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-01-20only enable windows incremental linking for debug buildsNoel Grandin
not necessary for optimised builds Change-Id: I33e7ff372b8b2fd35d6d45b552aceda36aaeba95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87054 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-18use -Wl,-dead_strip on Mac, its linker doesn't know -Wl,--gc-sectionsLuboš Luňák
Change-Id: Ic69d0030a46fe4753cc75da58bb2c15cf009b135 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87023 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-18support Clang's -fmodules-codegen/debuginfo options for PCH buildingLuboš Luňák
These (starting with my patches for Clang-to-be-10) allowing emitting debuginfo and functions into a dedicated object file, so that all the normal compilations using the PCH can skip those, thus saving the time. The debuginfo option seems to always be worth it. The codegen option is more tricky, it doesn't seem to be worth it for optimized builds (optimizing all the functions in that one object file costs too much). This requires also using --Wl,--gc-sections . The reason is that the object file contains all template instances instantiated from the PCH, so that they can be shared, but the template instance may come from another library or use a private symbol from that library. For example the std::unique_ptr<ScInterpreterContext> in ScInterpreterContextPool in the header refers to ScInterpreterContext dtor. But even though both these classes are private, the header gets used also by scfilt, because there it is included by document.hxx because of a private ScDocument data member. So even though nothing in scfilt uses ScInterpreterContext, the PCH object file will refer to it. Fortunately that template instance itself is not used by scfilt, so --gc-sections will remove it. Change-Id: I2a06ebcc4dd4175424b3a72ab3ebcaf2ac3ee295 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87011 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>
2020-01-09Get PDB files to work for soffice.bin and unopkg.binJuergen Funk
..by renaming them to *.bin.pdb, so WinDbg picks them up. Follow-up fix to commit 6ca3adf22b62b88b313c8fc9311183efdabe445a Change-Id: I5cb7b305c997b423cf0cd70835163811f75b3e25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86465 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-01-08Enable Clang -Wembedded-directiveStephan Bergmann
...which might have helped avoid the confusion with patch set 6 of <https://gerrit.libreoffice.org/c/core/+/84765/6> "python3: upgrade to release 3.7.6", in that it would have reported: > pyuno/source/module/pyuno.cxx:340:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive] > #if PY_VERSION_HEX >= 0x030200f0 > ^ > pyuno/source/module/pyuno.cxx:342:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive] > #else > ^ (-Wembedded-directive was introduced with <https://github.com/llvm/llvm-project/ commit/300237f00c7ddf9c74de96272f2bb571fda61202> "Add a warning flag for ext_embedded_directive. gcc considers this undefined" in 2011, so should be available in all versions of Clang relevant for us.) Change-Id: I4d90212aac30ba8715496d8c99cc6de05c6dc99a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86394 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-06macOS /usr/bin/mktemp already adds a dot to the prefixStephan Bergmann
(at least the version on macOS 10.15.2 does) Change-Id: Ie7525216542e1db686adb151774d20ff69d9e8f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86252 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-19Fix typo in codeAndrea Gelmini
Change-Id: I7c71e16628819bd60664f9b4dc70f0f0762afb48 Reviewed-on: https://gerrit.libreoffice.org/85521 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2019-12-16Revert "Make font-based unit test depend on instdir fonts"Jan-Marek Glogowski
The following build: $ make clean && make gb_CppunitTest_sc_ucalc [...] $ cd sc $ make gb_CppunitTest_sc_ucalc triggers: sc/CppunitTest_sc_subsequent_filters_test.mk:133: *** Missing font filelist -> run make more_fonts extras. This didn't help the general Win32 font build problem AFAIK. There were additional patches to the way Windows loads the LO provided fonts, so just revert this. This reverts commit 368c996b24e09c427a30972b3405493328db6779. Change-Id: I841f96fe8312c47980c8e3be2e9d88242df5b28d Reviewed-on: https://gerrit.libreoffice.org/84633 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-12Enable -Wdeprecated-copy-dtor where availableStephan Bergmann
We already get -Wdeprecated-copy (warning about implicitly defined copy functions that will in the future be deleted because other user-provided copy functions exist) automatically through -Wextra, where available. -Wdeprecated-copy-dtor (warning about implicitly defined copy functions that will in the future be deleted because of a user-provided dtor) is split off into its own warning excluded from -Wextra for somewhat unclear reasons, see the discussion at <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=88136> "-Wdeprecated-copy is draconian and shouldn't be in -Wall". But -Wdeprecated-copy-dtor has been useful in finding issues (esp. the Clang 10 trunk version, which, unlike the GCC 9 version, also finds copy functions that are implicitly defined because they are used from template instantiations), see 3e59716375a240576fd6d8759b32b4319506ed70 "Prevent BroadcastRecalcOnRefMoveHandler copies" and 4f98cd0f9ce9c2a331a5d34b3ef9d18f9bb6b235 "ScShapeChild has broken copy functions". We need to disable -Wdeprecated-copy-dtor in files included from external/boost, and in two compilerplugin/clang/test/ files. Change-Id: I74b159c3a046e23661473ddbfe53c92c4136a9db Reviewed-on: https://gerrit.libreoffice.org/85073 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-08Improve -fdiagnostics-color handlingStephan Bergmann
...following up on 13b52f50e52d226c935dcb94fac641c59a77f13f "gbuild: color gcc output if possible". Unconditional -fdiagnostics-color=auto overrode the -fdiagnostics-color=always I specify in CC/CXX to mitigate using the GNU Make -O option. Forcing -fdiagnostics-color=always iff gb_COLOR is set should give the desired results in all cases (colored output to a terminal when calling make without -O but using a GCC that defaults to -fdiagnostics-color=never, as well as colored output to a terminal when calling make with -O). Change-Id: I629bad4bceb15af3ed43f42038825bd1481b33dd Reviewed-on: https://gerrit.libreoffice.org/84710 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-08gbuild: color gcc output if possibleThorsten Behrens
Enable gcc to color its diagnostics output - depending on distro build flags, might need GCC_COLORS defined in the environment. See also gbuild.help.txt. Change-Id: Ibeaaaadcaccc2847c0105c266b977fee6f4e9960 Reviewed-on: https://gerrit.libreoffice.org/84705 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
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-12-04tdf#128133 WIN don't exit after link-output filterJan-Marek Glogowski
The linker output filter command (gb_filter_link_output) ends with an exit "${PIPESTATUS[0]}", which will quit the current Makefile shell command always after calling the linker. This prevents the later shell code of that line to run, which includes the merge of the DeclareDPIAware.manifest. That manifest would tell Windows that LO binaries are "<dpiAware>true</dpiAware>", to prevent System DPI scaling. Since it's not merged, LO is scaled by the OS, resulting in blurry fonts. Since there is no reason to have an extra make "function", like ifeq or multiple definitions, this includes the code directly. Additionally the MS linker has localized output, so this patch uses a more generic regexp to filter-out the default link message, which works with the English and German locale. Change-Id: I0099f6c38ca0eda18c7b0c108529bc73189c1504 Reviewed-on: https://gerrit.libreoffice.org/84099 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-11-27use the same config file for skia build and using itLuboš Luňák
So that the setup is consistent. Change-Id: Ia113c7bf79036e3ec7585263ed70da68e461fbac
2019-11-20/safeseh valid only on Win32Julien Nabet
On Win10 with master sources updated today + Visual Studio, I had this part: [build CXX] bridges/source/cpp_uno/shared/component.cxx Microsoft (R) Macro Assembler (x64) Version 14.23.28107.0 Copyright (C) Microsoft Corporation. All rights reserved. MASM : warning A4018:invalid command-line option : /safeseh Assembling: C:/BLP/core/bridges/source/cpp_uno/msvc_win32_x86-64/call.asm [build CXX] bridges/source/cpp_uno/shared/types.cxx See this link for rationale: https://docs.microsoft.com/en-us/cpp/build/reference/safeseh-image-has-safe-exception-handlers?view=vs-2019 According to https://bugzilla.mozilla.org/show_bug.cgi?id=581909 (9 years ago) "...For some reason ml64 ignores the -c following -safeseh..." I don't know if recent Visual Studio versions still ignore or not the following parameters but let's fix this Change-Id: I9ae5416f32429597fab35fcce8bf06707af4def5 Reviewed-on: https://gerrit.libreoffice.org/83230 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-15use icerun also for python/java/ui testsLuboš Luňák
Change-Id: If25c4949b999435e7a444d80a45f3dce9b8184ee Reviewed-on: https://gerrit.libreoffice.org/82715 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-23-W4 must come before -Wno-missing-braces for clang-clStephan Bergmann
...or else -W4 would re-enable that and cause lots of warnings/errors. 87608490f205b2fbc2b453ad8ded33050ac29b90 "filter arguments to MSVC to avoid the annoying D9025 warning" had changed the relative order of those options on the command line. Change-Id: I2ff9de93cdc6e3dc63961af61169f0adf44f7c0b Reviewed-on: https://gerrit.libreoffice.org/81403 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-15handle gracefully PCH reuse when there are no .pdb filesLuboš Luňák
In non-debug builds there are indeed no .pdb files to copy and reuse, and that's fine. Change-Id: I083a33ae81ac63b4e62f3a7cf0f8414996c6a843 Reviewed-on: https://gerrit.libreoffice.org/80812 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-14use common PCH for more librariesLuboš Luňák
Change-Id: I53164be413426691025a63cfba731cf5f9d1b7f8 Reviewed-on: https://gerrit.libreoffice.org/80790 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.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-14filter out cl.exe printing source file name also when not using depsLuboš Luňák
This is what filter-showIncludes.awk does as a side-effect, so this is for the --disable-dependency-tracking case. Change-Id: I0fd58ff4e343c6322e9cba641acd5fa2bf3816f4 Reviewed-on: https://gerrit.libreoffice.org/80731 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-12-fstack-protector-strong is long since availableStephan Bergmann
...on our baselines, since <https://gcc.gnu.org/git/ ?p=gcc.git;a=commitdiff;h=b156ec373ccf27f4fcce7972de5e043d35acea43> (GCC 4.9?) and <https://github.com/llvm/llvm-project/commit/ e0fc1a80cba8b91e3943f3287e7dcf68c6bb9b7f> "[stackprotector] Add command line option -fstack-protector-strong" (Clang 3.5?) Change-Id: I48237b2304a1ee273cc66f0bb458e890a5a2f21a Reviewed-on: https://gerrit.libreoffice.org/80700 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-10Duplicate -Wno-missing-bracesStephan Bergmann
...ever since 9055fb48402eaeb9ba876b7893e2f9a39fea06b1 "clang-cl: Enable more warnings etc. (like in the Clang/GCC case)" Change-Id: I2c7b36f6d0852ebf6c660e79e6a9bad057ec0153 Reviewed-on: https://gerrit.libreoffice.org/80608 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-09filter out the "Creating library" message from link.exeLuboš Luňák
It cannot be turned off, it doesn't bring any value and it pollutes gbuild output. Change-Id: Ie3684e5fc30c9c5d34bd991e928a8d3f11f0b823 Reviewed-on: https://gerrit.libreoffice.org/80492 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-07handle more -arch: options when avoiding D9025Luboš Luňák
Change-Id: I97ff0418e25aeaea4cae349f2d228fb35219b5c2 Reviewed-on: https://gerrit.libreoffice.org/80374 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-07enable -Wrange-loop-analysis on clangNoel Grandin
Change-Id: I2095308943c94ad16c110d5fac47715398eb5d39 Reviewed-on: https://gerrit.libreoffice.org/80187 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-04enable -Wunused-exception-parameter on clangNoel Grandin
which is useful because our MSVC build will warn about this by default Change-Id: Idcc0f08b69b6eda4dd2ab010a5fdb674787bebcf Reviewed-on: https://gerrit.libreoffice.org/80184 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-04filter arguments to MSVC to avoid the annoying D9025 warningLuboš Luňák
GCC/Clang do not bother with warning about overriding e.g. -O2 with -O0, AFAICT it's quite a common practice, and I really don't see any good reason for the warning, and even less so for not even being able to disable it. Without this, enabling SSE2/AVX2 would warn about overriding the default -arch:SSE (that's hardcoded by configure to be part of the compiler command). Change-Id: I9f9109b77de90085486bc2a98f1b453a41755e60 Reviewed-on: https://gerrit.libreoffice.org/80123 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-04common gbuild function for getting the correct windows compilerLuboš Luňák
Change-Id: Ia4001a4a3a0ac8490ab7104a25ccd688d18b8aa1 Reviewed-on: https://gerrit.libreoffice.org/80122 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>
generated by cgit (git 2.34.1) at 2025-01-06 14:43:16 +0000