| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I617f606b64706e8bc32e827644e5f1d1ef27702a
Reviewed-on: https://gerrit.libreoffice.org/78624
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Jenkins
|
|
The current dependency is already a hack, because there is no way
I know of to depend on delivered top-level modules like more_fonts.
The original patch parses the gb_Package_MODULE_ooo_fonts list of
registered packages to add them as build dependencies.
But this is not sufficient, as it just adds the dependencies on the
installed / unpacked fonts in the workdir (actually it's just the
installer filelist), where they can't be found by the unit test
running in the instdir environment.
So this converts the depndency into a make error, if either the
filelist is missing or the included font files. But if we are in
a full run and know the more_fonts module, we simply depend on its
delivered files.
This needs some minimal changes to gbuild, as neither the delivered
file list nor the modules class names are yet available. And this
moves the fontconfig handling to extras, where the opensymbol font
is already handled.
Change-Id: I1b70a4c45ff189266ce56c57e534ddc45e7c5c19
Reviewed-on: https://gerrit.libreoffice.org/74624
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The forwarding of LinkTarget subclass functions to LinkTarget functions
is currently done in a very elegant way that only requires listing the
bare function names once, but the downside is that the subclass
functions aren't defined in a way that "git grep" or "ctags" can find,
so replace that with more verbose copy-paste definitions.
Change-Id: I4bd7f1b1bc0904ae345958e39403ab508db584a1
Reviewed-on: https://gerrit.libreoffice.org/43196
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
* 994e38e336beeacbd983faafac480afc94d3947e "loplugin: use TypeCheck instead of
getQualifiedNameAsString" had effectively disabled this plugin (Asserter is a
struct, not a namespace). Fixed that.
* Also improved the checks, for one removing the---expensive---use of
Plugin::parentStmt, for another making the plugin look into (...), !..., and
...&&... expressions.
* However, as the plugin had effectively already been disabled (see above) when
it was switched on generally with 839e53b933322b739a7f534af58c63a2c69af7bd
"compilerplugins: enable loplugin:cppunitassertequals by default", it now hit
way more places than I had initially anticipated. To keep the amount of work
manageable, midway-through I disabled looking into ...&&... expressions for
now. That will be enabled (and resulting warnings fixed) in follow-up
commits.
* Checks like
CPPUNIT_ASSERT(a == b)
that actually want to check a specific overloaded operator == implementation,
rather than using such an operator == to actually check that a and b are
equal, can be rewritten as
CPPUNIT_ASSERT(operator ==(a, b))
to avoid false warnings from this plugin.
Change-Id: If3501020e2d150ad0f2454a65a39081e31470c0f
|
|
...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>
|
|
Change-Id: Ib35d8fcc41e1c49bfef01c980b25c051190cb753
Reviewed-on: https://gerrit.libreoffice.org/32990
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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
|
|
...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
|
