summaryrefslogtreecommitdiff
path: root/compilerplugins/Makefile-clang.mk
AgeCommit message (Collapse)Author
2019-11-25use -Xclang -fno-pch-timestamp also for Clang PCH in compilerpluginsLuboš Luňák
We already use that normally, the build system should generally take care of this by gmake dependencies. One exception is system headers, but those usually do not really change even if their timestamps do, so this should prevent Clang from giving an error about this after system headers update (which should be harmless, and if it isn't then I suppose either something else such as compiler upgrade should trigger a rebuild, or cleaning needs to be done manually). Change-Id: I60581c0d2d3233aadc60e1c90bd62cb9ad684ba2 Reviewed-on: https://gerrit.libreoffice.org/83662 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-21Don't invoke the linker when generating pch filesStephan Bergmann
When `llvm-config --cxxflags` outputs -Wl,... options (as has been discussed at 824d9394b529bb1fc521e4a4df8c4e3458ec5641 "Properly handle comma in CLANGFLAGS", and which end up on the compiler command lines here), Clang failed with an error "cannot specify -o when generating multiple output files" when generating sharedvisitor/clang.pch. Change-Id: I200ebd152f5a524ce7ecdd2f25c34bbaa634f515 Reviewed-on: https://gerrit.libreoffice.org/81065 Tested-by: Jenkins Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-18Properly handle comma in CLANGFLAGSStephan Bergmann
...which would cause an error that STRINGIFY takes only a single argument. According to chris_wot on IRC, LLVM 6.0 on Ubuntu 18.04.3 LTS output of `llvm --cxxflags` (as is used in configure.ac to determine what ultimately ends up in CLANGFLAGS here) includes e.g. -Wl,--no-keep-files-mapped. Change-Id: Iff570840fe62c2aa2d972431e610a05fe2f6922c Reviewed-on: https://gerrit.libreoffice.org/81037 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2019-10-15use PCH for clang plugin source too, if enabledLuboš Luňák
This currently supports only building with Clang on Linux, as I'm lazy to handle the other cases (and Clang should be usually self-built anyway). The main compile time cost is in optimizing the code, but this still saves few seconds per source. Change-Id: Ib6c0fd874820af737ee1257cb5234fb78bc63ad8 Reviewed-on: https://gerrit.libreoffice.org/80810 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-09fix compilerplugins makefile typoLuboš Luňák
Change-Id: Iff01d234746221a775c7b4f5742ae508691a90d0
2019-10-08My Windows clang-cl build still doesn't use LO_CLANG_SHARED_PLUGINSStephan Bergmann
...so disable the new configure.ac checks introduced with ad5cbcf6ba0afdc1d8d7405c2641cce8de4a360b "try to autodetect flags needed to build Clang plugins" that are only relevant when using LO_CLANG_SHARED_PLUGINS and would fail miserably for my clang-cl build Change-Id: I58f7f1f4608f1a615175f0c0d0d98c03c442a36c Reviewed-on: https://gerrit.libreoffice.org/80477 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-08More generated files to take care ofStephan Bergmann
Change-Id: I4a150389e42959bb8e522dbf488eda24ac934f00 Reviewed-on: https://gerrit.libreoffice.org/80422 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-07try to autodetect flags needed to build Clang pluginsLuboš Luňák
Instead of having a lot of it hardcoded, which brings problems like: - Clang-to-be-10 has switched to -std=c++14, so our hardcoded c++11 makes the build fail - I cannot compile with my openSUSE-shipped clang, because it ships only libclang-cpp and not the other libClangSomething libs The possibility to explicitly set the necessary variables is still there. Change-Id: I58d401d4584fa064f1c1351a8a06ff4e29643063 Reviewed-on: https://gerrit.libreoffice.org/80300 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-07generate make dependencies also for clang.pchLuboš Luňák
Change-Id: Id05f2741763ef0d9e87d9804339d29aee6bc068f Reviewed-on: https://gerrit.libreoffice.org/80380 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-06the PCH in compilerplugins should also depend on the MakefileLuboš Luňák
Otherwise it may not get rebuilt in Jenkins when flags in the Makefile change. Change-Id: I9a06c5bbfd4af2714497c5658d8c523a6c929f68 Reviewed-on: https://gerrit.libreoffice.org/80318 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-09-20rebuild sharedvisitor.cxx if any of its sources disappearsLuboš Luňák
Testcase: Remove any reference to LO_CLANG_SHARED_PLUGINS from e.g. blockblock.cxx, sharedvisitor.cxx should get regenerated. Change-Id: Iddff3cf41c223cfdf161060d29bde9df1df7b702 Reviewed-on: https://gerrit.libreoffice.org/79194 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-09-17Fix compilerplugins for macOS againStephan Bergmann
...in the same spirit as how COMPILER_PLUGINS_TOOLING_ARGS had been introduced with ad7e2af4ed0c11f8571374fbb40d38b38c27959c "Allow to pass additional options into generator's clang::tooling": For one, ceb26770b3d1c5c2ffaf73f8f589c5e169e6db06 "split clangplugins sharedvisitor generator into two steps" should have passed COMPILER_PLUGINS_TOOLING_ARGS only into the analyzer and not into the generator executable, while for another, at least my local build failed with > [PCH] compilerplugins/clang/sharedvisitor/clang.pch > In file included from /Users/stephan/Software/lo/core/compilerplugins/clang/sharedvisitor/precompiled_clang.hxx:12: > In file included from /Users/stephan/Software/lo/core/compilerplugins/clang/sharedvisitor/../plugin.hxx:15: > In file included from /Users/stephan/Software/llvm/inst/include/clang/AST/ASTContext.h:18: > In file included from /Users/stephan/Software/llvm/inst/include/clang/AST/ASTTypeTraits.h:19: > In file included from /Users/stephan/Software/llvm/inst/include/clang/AST/Decl.h:16: > In file included from /Users/stephan/Software/llvm/inst/include/clang/AST/APValue.h:16: > In file included from /Users/stephan/Software/llvm/inst/include/clang/Basic/FixedPoint.h:19: > In file included from /Users/stephan/Software/llvm/inst/include/llvm/ADT/APSInt.h:17: > In file included from /Users/stephan/Software/llvm/inst/include/llvm/ADT/APInt.h:18: > In file included from /Users/stephan/Software/llvm/inst/include/llvm/Support/Compiler.h:21: > In file included from /Users/stephan/Software/llvm/inst/bin/../include/c++/v1/new:90: > In file included from /Users/stephan/Software/llvm/inst/bin/../include/c++/v1/exception:81: > In file included from /Users/stephan/Software/llvm/inst/bin/../include/c++/v1/cstdlib:85: > /Users/stephan/Software/llvm/inst/bin/../include/c++/v1/stdlib.h:97:15: fatal error: 'stdlib.h' file not found > #include_next <stdlib.h> > ^~~~~~~~~~ after dc79dc76f18148296ae18ed7251cf61505e25d44 "make clangplugin analyzer use internally a PCH to speed things up". Change-Id: I4aa925049dbc145c672cad7cab2043a0f13780fa Reviewed-on: https://gerrit.libreoffice.org/79028 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-11Adapt compilerplugins.cleanStephan Bergmann
...to ceb26770b3d1c5c2ffaf73f8f589c5e169e6db06 "split clangplugins sharedvisitor generator into two steps" Change-Id: If75495e9d57007bb30e69e74842bcf42457c9ee4 Reviewed-on: https://gerrit.libreoffice.org/78820 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-06make clangplugin analyzer use internally a PCH to speed things upLuboš Luňák
This generally makes the sharedvisitor performance reasonable. The only costly thing that remains is compiling the large sharedvisitor.cxx, which with optimizations takes quite some time, but there's ccache for that. Change-Id: Iffa5fc9df34cdb5edf1cde34fc558fd007ef8263 Reviewed-on: https://gerrit.libreoffice.org/78569 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-09-06split clangplugins sharedvisitor generator into two stepsLuboš Luňák
Analysing all the plugin sources using just one process takes a lot of time, so split out a separate analyzer tool that'll analyse one source and print out the data to a .plugininfo file. The generator then will read all of these and generate sharedvisitor.cxx . This allows parallelising the expensive analysis. With this commit sharedvisitor.cxx is no longer included in the repository, as this and the next commit should make the generation fast enough. Change-Id: Idfc33c4ea6ccfd84f829b51001c8ddeb0be09961 Reviewed-on: https://gerrit.libreoffice.org/78568 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-08-30adapt to runToolOnCodeWithArgs API change in clang 10Noel Grandin
which required including config_host in generator, which in turn required adapting the makefile Change-Id: Icafa3b59816f52c349fbbd76ce71305856c9ce33 Reviewed-on: https://gerrit.libreoffice.org/78293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-15LLVM trunk requires C++14 nowStephan Bergmann
...which caused failures like > [GEN] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx > In file included from /data/sbergman/lo/core/compilerplugins/clang/badstatics.cxx:14: > In file included from /data/sbergman/lo/core/compilerplugins/clang/check.hxx:15: > In file included from /data/sbergman/llvm/inst/include/clang/AST/DeclBase.h:18: > In file included from /data/sbergman/llvm/inst/include/clang/AST/DeclarationName.h:16: > In file included from /data/sbergman/llvm/inst/include/clang/AST/Type.h:48: > /data/sbergman/llvm/inst/include/llvm/Support/TrailingObjects.h:252:24: error: no member named 'is_final' in namespace 'std' > static_assert(std::is_final<BaseTy>(), "BaseTy must be final."); > ~~~~~^ [...] However, unconditionally using -std=c++14 in generator.cxx would cause failures for builds against older Clang (and with COMPILER_PLUGINS_CXX specifying -std=c++11) on machines that have an old C++11-only system libstdc++. Those machines typically use --gcc-toolchain to use a newer non-system libstdc++ (cf. e.g. setting CC and CXX in lode's bin/linux_clang_dbgutil_64.env), so one solution could be to propagate such an option from CXX through to generator.cxx. But the easier fix appears to be to instead propagate the -std option. Change-Id: Ib081754ce8ad567305d1520e3a1ff6700fb22755 Reviewed-on: https://gerrit.libreoffice.org/77502 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-16macOS ld doesn't know --rpathStephan Bergmann
Change-Id: I4ebef2f15c409805adcd16916a9137b94e4ee535 Reviewed-on: https://gerrit.libreoffice.org/75677 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-25help compilerplugins generator find clang shared libs, if neededLuboš Luňák
Change-Id: I892aa42bc1e94823ab52cdfd6a855bf90106306d Reviewed-on: https://gerrit.libreoffice.org/74681 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-06-25do not use -g unconditionally for building the clang pluginLuboš Luňák
The generated files are ~700MiB here, compared to ~85MiB without. Change-Id: I76bafc59ff89fd7eb8ffbc4b9ad79bc63da8f064 Reviewed-on: https://gerrit.libreoffice.org/74678 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-05-27fix compilerplugin rebuilding when system clang changesLuboš Luňák
Since Clang doesn't keep backwards binary compatibility, it's necessary to rebuild when Clang (major version?) changes. This was broken because e.g. check.cxx didn't include plugin.hxx, and so it didn't depend on config_clang.h . Now simply force timestamp change if config_clang.h changes. This still needs re-running configure though. Change-Id: Icbc404b37105599f1ca6c8996f5a3d45d50082db Reviewed-on: https://gerrit.libreoffice.org/72976 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-05-27sharedvisitor generator should also be rebuilt if clang changesLuboš Luňák
Change-Id: I7602974ed6f4969ec9f79504bdb72758a747d39a Reviewed-on: https://gerrit.libreoffice.org/72982 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-05-23Avoid putting generator.dwo in current working dirStephan Bergmann
At least some versions of GCC put the -gsplit-dwarf .dwo file in cwd when compiling and linking is done together in one compiler invocation, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90575> "-gsplit-dwarf leaves behind .dwo file in cwd". Change-Id: I1b418e400a3e8107997fbbfd7f87ef3ac9fbbd28 Reviewed-on: https://gerrit.libreoffice.org/72841 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-05-20use -gsplit-dwarf also for compilerplugins if possibleLuboš Luňák
~350MiB easily saved. Change-Id: I9a91894cf4df7bc06d472795e564148fe8342995 Reviewed-on: https://gerrit.libreoffice.org/72588 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-03-27Disable LO_CLANG_SHARED_PLUGINS on Windows for nowStephan Bergmann
...needs some more modifications to make it work with clang-cl Change-Id: I6e2f8c9651b0532e21ec5acf94e8bae0a0f8f06e Reviewed-on: https://gerrit.libreoffice.org/69808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-23Consistently make generator invocation $(QUIET) tooStephan Bergmann
Change-Id: I5251f130aafdebdb4698ef4513b1dcf9f3bdf454 Reviewed-on: https://gerrit.libreoffice.org/69571 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-22Allow to pass additional options into generator's clang::toolingStephan Bergmann
In my macOS build, that clang::tooling::runToolOnCodeWithArgs invocation failed to find headers like cassert and assert.h, which works now with COMPILER_PLUGINS_TOOLING_ARGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -isystem /Users/stephan/Software/llvm/inst/include/c++/v1 added to my autogen.input (I build against my Clang trunk libc++ whose headers are at /Users/stephan/Software/llvm/inst/include/c++/v1). Change-Id: Idbffa39c9fd4a88743fd498b8f7b6c9c56d7630d Reviewed-on: https://gerrit.libreoffice.org/69538 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-18It is building the generator exe that depends on $(CLANGOUTDIR)/sharedvisitorStephan Bergmann
...or else -MF $(CLANGOUTDIR)/sharedvisitor/generator.d in the command line for building the generator exe could produce a failure because the dir does not exist yet. (The dependency of compilerplugins-build on $(CLANGOUTDIR)/sharedvisitor had been added with adb08e892b37ea9e155abbdee4e0c9951a1d163b "make (some) clang plugins share the same RecursiveASTVisitor" for reasons that are not clear to me.) Change-Id: I124b95be5e8ba36dc5d7502208c61ccf045516f5 Reviewed-on: https://gerrit.libreoffice.org/69307 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-12make (some) clang plugins share the same RecursiveASTVisitorLuboš Luňák
Each plugin currently uses its own recursive AST run, which adds up. This patch adds another shared plugin which internally contains all (suitable) plugins and dispatches to them from the same one recursive run. This patch converts ~25 plugins and for starmath's accessibility.cxx reduces clang build time from 5.43s to 5.14s (and it's 4.39s without any plugins). As there are almost 50 more plugins to go, this can theoretically result in 4.56s final time, although probably not all plugins can be that easily converted, if at all. This mostly requires very little change in many plugins (see e.g. BadStatics), some even work without any functionality change (e.g. CharRightShift). Traverse* calls require some changes but are often not that difficult. WalkUp* probably can't be supported, although some plugins can(?) possibly be adjusted to not rely on them. And of course some plugins can be left as they are, using their own recursive run. See description at the top of generator.cxx for description of how to convert a plugin. The sharedvisitor.cxx source is generated based on scanning relevant plugin sources using a clang-based scanner/generator. The generated source is intentionally included instead of getting always generated, as the generating currently takes some time, so it should get updated in git whenever a change in a plugin triggers a source change in it. Change-Id: Ia0d2e3a5a464659503dbb4ed6c20b6cc89b4de01 Reviewed-on: https://gerrit.libreoffice.org/68026 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-02-18make Makefile-clang.mk also use gb_Output_announceLuboš Luňák
So that the output is consistent, even though the actual build handling is different. Change-Id: I460dfe4c2ac74515cc1b598d47e119eb249b8277 Reviewed-on: https://gerrit.libreoffice.org/67972 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-02-18make uninteresting code in clang's makefile to the uninteresting partLuboš Luňák
Change-Id: I235284c7198aa2a295b4d81ff2f8e9ca554a4174 Reviewed-on: https://gerrit.libreoffice.org/67971 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2017-12-06Remove CXXFLAGS_CXX11 from Clang plugin compilationStephan Bergmann
CXXFLAGS_CXX11 is for the compiler used to compile LO proper. The plugin needs to be compiled in a way compatible with compiling Clang, and the compiler and any relevant flags can be controlled with COMPILER_PLUGINS_CXX. (And at least on macOS when compiling LO against a locally-built recent Clang trunk, CXXFLAGS_CXX11 will now contain -std=gnu++17, but COMPILER_PLUGINS_CXX can still point at Apple's Xcode clang++, which does not understand -std=gnu++17.) Also, if COMPILER_PLUGINS_CXX is not set, simply default it to g++ instead of trying to construct an acceptable CLANGCXX value from CXX (which would be Clang). (The problem with using Clang without CXXFLAGS_CXX11 is that Clang, unlike GCC, typically defaults to C++03, but building compilerplugins requires C++11 at least. That would cause e.g. the Gerrit/Jenkins linux_clang_dbgutil_64 builds to fail---but which also needs COMPILER_PLUGINS_CXX to be explicitly set to "g++ -std=c++11" as GCC on those machines is still 4.8.5 defaulting to C++03.) Change-Id: Id4ee4e54fa871cb6e621069cd050ae5b31922b34 Reviewed-on: https://gerrit.libreoffice.org/45856 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-09-30Support loplugin in clang-clStephan Bergmann
This works at least with a recent Clang trunk (towards Clang 6.0). In order for the plugin.dll to find the LLVM/Clang symbols, it needs to be loaded into clang.exe not clang-cl.exe, so set CC/CXX to 'clang.exe --driver-mode=cl ...'. Buidling the plugin requires some linker flags that must go at the very end of the COMPILER_PLUGINS_CXX command line, after a /link switch, so introduce another COMPILER_PLUGINS_CXX_LINKFLAGS variable for that. Also, clang.lib is not installed as part of LLVM's 'cmake --build ... --target install' step, so is not available under CLANGDIR and needs to be taken from the build tree instead, so introduce another CLANGLIBDIR variable for that. autogen.input settings that work for me on Windows 8.1 with Microsoft Visual Studio 14.0 are: > CLANGDIR=C:/llvm/inst > CLANGLIBDIR=C:/llvm/build/lib > COMPILER_PLUGINS_CXX=C:/PROGRA~2/MICROS~3.0/VC/bin/amd64/cl.exe /IC:\PROGRA~2\MICROS~3.0\VC\INCLUDE /IC:\PROGRA~2\MICROS~3.0\VC\ATLMFC\INCLUDE /IC:\PROGRA~2\WI3CF2~1\10\include\100102~1.0\ucrt /IC:\PROGRA~2\WI3CF2~1\NETFXSDK\46D346~1.1\include\um /IC:\PROGRA~2\WI3CF2~1\8.1\include\shared /IC:\PROGRA~2\WI3CF2~1\8.1\include\um /IC:\PROGRA~2\WI3CF2~1\8.1\include\winrt > COMPILER_PLUGINS_CXX_LINKFLAGS=/LIBPATH:C:/PROGRA~2/MICROS~3.0/VC/LIB/amd64 /LIBPATH:C:/PROGRA~2/MICROS~3.0/VC/ATLMFC/LIB/amd64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/10/lib/100102~1.0/ucrt/x64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/NETFXSDK/46D346~1.1/lib/um/x64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/8.1/lib/winv6.3/um/x64 (The last two are "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/ amd64/cl.exe" and translations of %INCLUDE% and %LIB% as set in the "VS2015 x64 Native Tools Command Prompt" shell. AC_CHECK_HEADER(clang/AST/RecursiveASTVisitor.h, ...) in configure.ac wouldn't like CXX to start with INCLUDE=... LIB=... environment variable settings, so it wouldn't work to instead pass %INCLUDE% and %LIB% to cl.exe that way. See <https://wiki.documentfoundation.org/Development/clang-cl> for general information about building with clang-cl on Windows.) There's still some room for improvement marked "TODO". (And some of the unused* plugins, which are not run by default anyway, use Unix-style functionality, so have been disabled for now.) Change-Id: I6c28bdeb801af39ce2bae03111f455e2338d66c9 Reviewed-on: https://gerrit.libreoffice.org/42931 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-05-16Also filter out flags like -fsanitize-address-globals-dead-strippingStephan Bergmann
...to avoid -Werror,-Wunused-command-line-argument in case some ASan build setting passes in such flags Change-Id: Ia613a10e3564a23715019ee0c7c755cdcbf7a47c
2016-06-30Explain usage of -isystem instead of -IStephan Bergmann
Change-Id: Ib7153db5c2c1542ff7e9a0daa6d7124225c7701c
2016-06-30Who needs that $(CLANGDIR)/tools/clang/include anyway?Stephan Bergmann
It was included ever since 02a8d36ebf3d54784903f2899eafe010bedf2f4c "initial support for clang compiler plugins" but will probably point at either a non- existing dir or a dir in the Clang source tree (that does not even contain all the include files that the corresponding installation dir would contain, as some include files are generated during the build). For a properly installed LLVM/ Clang, all include files should be found underneath a single include/ dir. Change-Id: Ie23cb1ae701eed1ee78448eb6c828d07b15121c2
2016-06-29compilerplugins: -isystem /usr/include breaks the buildMichael Stahl
... on Fedora 24, and it's a Bad Idea in general because it breaks "#include_next" ordering of GCC's and glibc's variously distributed headers. Change-Id: I0c8b51a6d7191ec9cc5187636ea2717e8fd97715
2016-02-26New COMPILER_PLUGINS_CXX to specify compiler to build Clang plugins withStephan Bergmann
...instead of trying to second-guess what to strip off $(CXX) to make it fit. Keep the old way for existing build scripts that rely on it. Change-Id: I145bdcba6d02002a9b653b4deb6e7f5a9c76cc8f
2016-02-26These version checks are about the Clang the plugins are built /against/Stephan Bergmann
...not the (Clang) compiler they are being built /with/. (Also simplifies the checking #if code.) Change-Id: I416321be4ef4478785be40571f81500fd3b6feb8
2015-08-11gbuild/config stop using VERBOSE, use only verbose=tNorbert Thiebaud
configure.ac was setting VERBOSE=YES/NO when really we use verbose=t or verbose= Change-Id: I47aee8d177cb2d788a62ecdbbb9cc3695c2bb299 Reviewed-on: https://gerrit.libreoffice.org/17634 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
2014-05-22Filter out all -fsanitize= args when building compilerpluginsStephan Bergmann
Change-Id: Ic809ddad81608f107749498c1432606403ee2314
2014-05-17Correct common misspellings, and remove some ASCII art along the way.Chris Laplante
Change-Id: I42787db31769e8bde984c5f4f0aa90335e889b1c Reviewed-on: https://gerrit.libreoffice.org/9356 Reviewed-by: Thomas Arnhold <thomas@arnhold.org> Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
2014-05-09compilerplugins/clang: filter out -fsanitize=addressStephan Bergmann
Change-Id: I3e78bd86c8010124a2d006f288095aac26e60797
2014-02-25Drop CLANGBUILD in addition to CLANGDIRStephan Bergmann
...see <http://lists.freedesktop.org/archives/libreoffice/2014-February/059654.html> "Drop CLANGBUILD in addition to CLANGDIR?" Change-Id: I8d68aa0f2298240c8e7265cab273c602f5b6881a
2014-02-21Allow building compilerplugins/clang on Mac OS XStephan Bergmann
(at least against a self-built Clang configured --enable-keep-symbols) Change-Id: I6e38688c78f78aca1864530042159cdcef7a0694
2014-02-20EXTERNAL_WARNINGS_NOT_ERRORS -> ENABLE_WERROR and be "TRUE"/""Matúš Kukan
It's easier to type 'make ENABLE_WERROR= <module>' if one wants that. Change-Id: I2bb9911259f41ecae27dc110723f3364b3ff09cf
2014-01-10compilerplugins: strip out -m32/-m64 from CXXMichael Stahl
These are not part of LO and need to be built with native bitness of the compiler. Change-Id: I41fdec130a63e0c0d07f1df228031014cd2351c2
2013-08-05clang binary is in clang build directory, not with its sourcesLuboš Luňák
Change-Id: If037eac010d3cb72ca185382232c211758d009e6
2013-06-13work around the C++11 __float128 problem with libstdc++ headers and clangLuboš Luňák
Change-Id: Ia1b443d22b3b7f6f93f1ad8c5fa760b0f1da3b83
2013-06-05Ignore warnings in Clang headersStephan Bergmann
(as occur at least in trunk Clang builds) Change-Id: I7e74200ae1042133fa04477e39e46fd2f01cc1b0
generated by cgit (git 2.34.1) at 2025-01-15 23:36:02 +0000