This statement adds a VIEW "buildbot_overview" containing all relevant
information for a build. I plan to extend this file with additional
views when needed.
The current version of Python fails to build some dependencies, but
pinning the previous version works.
ActivePerl is no longer installable via Chocolatey (neither current
nor older versions) as ActiveState don't provide the downloads
without registration any longer (and even if registered, only
provide the latest, continuously updated version for free users, which
can't match the package manager checksums), see http://disq.us/p/2ipditb
for further discussion.
Replace ActivePerl with StrawberryPerl. StrawberryPerl has other
drawbacks, as it installs a whole C/C++ toolchain as part of it,
and copies of pkg-config tools that can cause package misdetections.
Remove these after installing it, see
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/11
for discussion on the inconveniences of installing it.
This bundles clang/lld and associated tools, configured for a mingw
target, with corresponding mingw sysroots.
As we already install the 'llvm' chocolatey package, which also
provides clang (defaulting to a MSVC target), add this one last in the
path. This lets 'clang' refer to the default MSVC-targeting tool, while
one can use a GCC style triple prefixed driver name, like
x86_64-w64-mingw32-clang, to use this tool.
This allows setting up a much-needed mingw configuration for the libcxx
CI.
The current setup is configuring the "affected projects" as well
as their dependencies, and run `ninja all` followed by
`ninja check-all`.
This is quite a pessimization for leaf project which don't need to
build and run the tests for their dependencies.
For example a patch affecting only MLIR shouldn't need to build
and run LLVM and clang tests.
This patch changes this by running checks only for the affected
project. For example a patch touching `mlir` is affecting `mlir`
and `flang`. However `flang` depends on `clang`. So the list of
projects to configure is `mlir;flang;clang;llvm;`, but we want
to test only mlir and flang ; we'll run only `ninja check-mlir
check-flang`.
In practice in this example running `ninja all` builds 5658 targets
and `ninja check-all` after that adds 716 more targets. On the other
hands `ninja check-flang check-mlir` results in 3997 targets total.
Concretely the contract with premerge_checks.py is changed so that
the expected argument for the --projects flag is only the list of
affected project, dependencies are automatically added.
"git diff" handles text files encoded that is not valid UTF-8 (e.g
using ISO-8859-1) as text files and produces a diff of those (rather
saying "Binary files a/x and b/x differ").
This means that the diff output may contain such characters. Files
that did would cause clang_tidy_report.py do hit an UnicodeDecodeError
when reading the diff, including if it was on removed lines and
regardless if it was in the ignore file.
By specifying errors mode "replace" for decode() method the bytes
that are not a valid utf-8 encoding are replaced with the unicode
replacement question mark (U+FFFD). When parsing the diff
clang-tidy-diff is only looking at filenames and line numbers of the
diff, so this shouldn't be a problem if it doesn't get the exact same
byte sequence inside the actual change.
I created a new queue for the pre-merge checks so that they won't compete for resources
with the post-merge build already running. Obviously that creates some inefficiency, but is
a simple way to make sure neither build gets starved (in particular, we know that the
current setup of 4 agents running on a single 32-core VM is enough to handle the commit
traffic on the main branch whereas pre-merge testing volume is likely to be more
unpredictable.
