[all-commits] [llvm/llvm-project] 0198d7: [Bazel] Get `//clang` building on Windows with cla...

[Chandler Carruth via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0198d76e1e76ff4701df33d34ece3259c4d3aeef
      https://github.com/llvm/llvm-project/commit/0198d76e1e76ff4701df33d34ece3259c4d3aeef
  Author: Chandler Carruth <chandlerc at gmail.com>
  Date:   2021-11-02 (Tue, 02 Nov 2021)

  Changed paths:
    M utils/bazel/.bazelrc
    M utils/bazel/llvm-project-overlay/clang/BUILD.bazel
    M utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h
    M utils/bazel/llvm-project-overlay/clang/unittests/BUILD.bazel
    M utils/bazel/llvm-project-overlay/llvm/cc_plugin_library.bzl
    M utils/bazel/llvm-project-overlay/llvm/config.bzl
    M utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/config.h

  Log Message:
  -----------
  [Bazel] Get `//clang` building on Windows with clang-cl.

This required substantially more invasive changes.

We need to handle some of the LLVM `config.h` changes differently from
the old pattern. These aren't always safe on the commandline, and the
Windows ones specifically break Clang. Instead, use conditional defines
in the header itself. This more closely matches how CMake builds see the
definitions. I think this is also just cleaner and we should maybe move
more of the macros out of Bazel.

The config defines for Windows that I've kept in Bazel are the ones that
LLVM's CMake does at the commandline as well. I've also added numerous
ones that CMake uses and we didn't replicate in Bazel.

I also needed a different approach to get `libclang` working well. This,
IMO, improves things on all platforms. Now we build the plugin and
actually wrap it back up with `cc_import`. We have to use a collection
of manually tagged `cc_binary` rules to get the naming to work out the
right way, but this isn't too different from the prior approach. By
directly having a `cc_binary` rule for each platform spelling of
`libclang`, we can actually extract the interface library from it and
correctly depend on it with `cc_import`. I think the result now is much
closer to the intent and to the CMake build for libclang.

Sadly, some tests also needed disabling. This is actually narrower than
what CMake does. The issue isn't indicative of anything serious -- the
test just assumes Unix-style paths.

I also have cleaned up the Windows flags in `.bazelrc` to much more
closely match what CMake does.

Differential Revision: https://reviews.llvm.org/D112399