You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[docker] More code sharing and use development clang for Bazel builds (iree-org#11108)
There's a lot going on here. I'd normally try to break things up into
separate PRs, but building and testing the Docker containers is labor
intensive, so this is all in one. I tried to create a sensible series
of commits for review, at least. If desired, I could do further cleanup
to the commits (give them all names that make sense with less context)
and merge this with a merge commit.
The original goal here was to use the development version of `clang` in
the Bazel build so that we can catch layering issues. Google uses a
close-to-head `clang` internally so we get the new diagnostics and
such and have to deal with them when pulling into the Google monorepo.
In particular, llvm/llvm-project@a002063de3
fixed a bug in the layering detection for `clang` which caused it to
catch a bunch more layering issues, fixed in
iree-org#11166. Given that some of the
main reasons to maintain the Bazel build are to ease integration into
Google's monorepo and to catch layering violations, it seems better to
use development `clang` for this build. Ensuring support for old clang
+ Bazel is not a particularly high priority, especially since few (no?)
project developers actually develop using Bazel.
While doing this, I did a bunch more cleanup though, partially as it
became the easiest way to make some changes.
- The restructuring in iree-org#11083 to
open up the Docker context enabled increased usage of shared scripts,
including those we use for non-Docker purposes.
- Similarly, I was able to limit the number of places where we specify
our minimum supported version. These have frequently not been kept in
sync (e.g. iree-org#8811 didn't bump the
SwiftShader version in our user install script).
- I codified Python package versions with pip requirements files
instead of having them scattered about Dockerfiles and documentation.
- I made all the containers build with "safe" bash by default.
- I bumped our *maximum* supported CMake version.
0 commit comments