commit 4fd7a1da7024bf3472d0daead099f868a6ecb1a7
author Geoffrey Martin-Noble <gcmn@google.com> Thu Nov 17 15:09:49 2022 -0800
committer GitHub <noreply@github.com> Thu Nov 17 23:09:49 2022 +0000
tree 8850b12a5df8d9c9d06ef907fa496a5230b3b4f8
parent 952aeca73a1093ffb4e60b9c591e6e3dabbe6b0c

[docker] More code sharing and use development clang for Bazel builds (#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, https://github.com/llvm/llvm-project/commit/a002063de3
fixed a bug in the layering detection for `clang` which caused it to
catch a bunch more layering issues, fixed in
https://github.com/iree-org/iree/pull/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 https://github.com/iree-org/iree/pull/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. https://github.com/iree-org/iree/pull/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.