Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
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>
|
|
...to avoid -Werror,-Wunused-command-line-argument in case some ASan build
setting passes in such flags
Change-Id: Ia613a10e3564a23715019ee0c7c755cdcbf7a47c
|
|
Change-Id: Ib7153db5c2c1542ff7e9a0daa6d7124225c7701c
|
|
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
|
|
... 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
|
|
...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
|
|
...not the (Clang) compiler they are being built /with/. (Also simplifies the
checking #if code.)
Change-Id: I416321be4ef4478785be40571f81500fd3b6feb8
|
|
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>
|
|
Change-Id: Ic809ddad81608f107749498c1432606403ee2314
|
|
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>
|
|
Change-Id: I3e78bd86c8010124a2d006f288095aac26e60797
|
|
...see
<http://lists.freedesktop.org/archives/libreoffice/2014-February/059654.html>
"Drop CLANGBUILD in addition to CLANGDIR?"
Change-Id: I8d68aa0f2298240c8e7265cab273c602f5b6881a
|
|
(at least against a self-built Clang configured --enable-keep-symbols)
Change-Id: I6e38688c78f78aca1864530042159cdcef7a0694
|
|
It's easier to type 'make ENABLE_WERROR= <module>' if one wants that.
Change-Id: I2bb9911259f41ecae27dc110723f3364b3ff09cf
|
|
These are not part of LO and need to be built with native bitness
of the compiler.
Change-Id: I41fdec130a63e0c0d07f1df228031014cd2351c2
|
|
Change-Id: If037eac010d3cb72ca185382232c211758d009e6
|
|
Change-Id: Ia1b443d22b3b7f6f93f1ad8c5fa760b0f1da3b83
|
|
(as occur at least in trunk Clang builds)
Change-Id: I7e74200ae1042133fa04477e39e46fd2f01cc1b0
|
|
Change-Id: I8ca9b09a6ffd4b2f00740563fa9682fdabb26b3d
|
|
At the top should be stuff to set manually if needed.
Change-Id: I516ac6df8102f00f6fc34c4c87d040688fcc2e99
|
|
Change-Id: I4397575e4665e8a257d0bd3e15245d996a48a1f4
|
|
Change-Id: I246dcf1d2c099c510435d21f0dd47e3c098456f2
|
|
Change-Id: I4849656b16c2a7103217870050b0de3ccb97af56
|
|
Otherwise there's an error message e.g. during a clean build.
Change-Id: I42efd08e014a4ebe25cfd1a497f622e5ea5c39ad
|
|
CLANGFORCE was the first in the makefile after
c6ffe17631cccf11fbe00479d2169116d494a7da and therefore the default
Change-Id: Id3b86a1ea2c27479067f7f55a977da3e6e8a2dfb
|
|
Change-Id: I7fdde46334c648ab6cba54210e31fada87dcfb55
|
|
This means that just moving sources to the dir will enable the plugin
action in that source, without modifying any sources, so those changes
would not be accidentally committed when using a rewriter to change
LO sources.
Change-Id: Ic5a9c52dbf1939a1e78ad39ed6691ce3a1f399df
|
|
Change-Id: Ifa1af34121bda9ca3250d09a3b8a46ea226795ed
|
|
Change-Id: I347790e1ca2ee6a27303d3644aa1459ff76ba4b0
|
|
If the clang binary comes from a package which had been built before
any of our clang related sources were changed the last time, the timestamp
would be older and so there would be no rebuild. So do the stamp handling
the usual way, clang upgrades will work fine, downgrades will not, but
that's the same problem like with downgrading a library and its headers.
To somewhat mitigate the problem (Clang plugin doesn't get cleaned by
'make clean'), include the full Clang version (which includes SVN revision)
in config_clang.h and make all Clang plugin code include that, so
at least configure re-run will trigger a rebuild if necessary.
Change-Id: I993197f79e92e36105092c92c33b2e1db343e975
|
|
Change-Id: I12bf38985ae62756973c05aacf762ae3c405ac9b
|
|
|
|
Change-Id: Ie4c934b52c4b010703e91f84b83e1fe590b5d187
|
|
...it just appeared to work on machines that happen to have /usr/bin/clang. So
hoist CLANGDIR/CLANGBUILD from compilerplugins/Makefile-clang.mk to configure.ac
instead.
Change-Id: Ie5d9c6bb8e9d0caa1583d78c8693f06b69873095
|
|
(i.e., configure with CLANGPLUGIN_CPPFLAGS=-I.../clang-installation/include
-I.../clang-build/tools/clang/include)
Change-Id: Ic6d2973629103f71c32f44ebba2ac70d137d18e7
|
|
Change-Id: I59a7490ec76b10fd31033d1ceccd1e3eae0ad398
|
|
Change-Id: I12e98ac9fc49ef2007914324006a396d183b778c
|
|
Some of the areas are guesses I've added after seeing them, whoever feels reponsible
for whichever part of the code feel free to adjust them.
Change-Id: I2192de84d51cc2bc7c28fa84019d38b465985d15
|
|
Change-Id: Ia312533381260a7c506dfd75b9f88c74a8329958
|
|
Change-Id: Ia4192224d0b217ba2393dc457250cf12febe9306
|
|
Change-Id: I628e3b99b69d238abc9df3e62e77b30eb85f1a0d
|
|
Change-Id: Ia84c70006b0b8a039b6fea27f3c5cde796f25d03
|
|
This is for variables that the compiler itself cannot figure out
(e.g. non-trivial ctors). The classes need to be marked manually.
Change-Id: I0109972e11e20578b1adc32065f701a871ee21aa
|
|
The plugin is intentionally built using a custom Makefile,
because it's used by gbuild, so I don't want to build the plugin
using gbuild too. It is also intentionally not placed under workdir/,
as that is cleaned by 'make clean', the plugin is cleaned only
by 'make distclean', so that cleaning it doesn't cause ccache misses.
No actual functionality in the plugin itself yet.
Change-Id: Ic05eba8d6260eec123c9e699eb5385abfe1b832f
|