[all-commits] [llvm/llvm-project] 5074a2: Don't define //mlir:MLIRBindingsPythonCore in term...

[Peter Hawkins via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5074a20dec70ef2afef650f770fb45eb0247a4f7
      https://github.com/llvm/llvm-project/commit/5074a20dec70ef2afef650f770fb45eb0247a4f7
  Author: Peter Hawkins <phawkins at google.com>
  Date:   2021-11-12 (Fri, 12 Nov 2021)

  Changed paths:
    M utils/bazel/llvm-project-overlay/mlir/BUILD.bazel

  Log Message:
  -----------
  Don't define //mlir:MLIRBindingsPythonCore in terms of the NoCAPI and CAPIDeps targets.

We noticed that the library structure causes link ordering problems in Google's internal build. However, we don't think the problem is specific to Google's build, it probably can be reproduced anywhere with the right library structure.

In general splitting the Python bindings from their dependencies (the C API targets) creates the possibility that the two libraries might end up in the wrong order on the linker command line. We can avoid this problem happening by reverting the structure of the MLIRBindingsPythonCore to represent its dependencies in the usual way, rather than composing an incomplete `MLIRBindingsPythonCoreNoCAPI` target and their CAPI dependencies. It was probably a mistake to rewrite this particular `cc_library()` rule in terms of the two, since nothing guarantees that the two will be correctly ordered by the linker when both are being linked into the same binary, and it was only an incidental "cleanup" done in passing.

Otherwise the previous PR (D113565) is fine, since that was about the case where both are being built into two separate shared libraries. It just shouldn't have made this (unrelated) change.

Reviewed By: GMNGeoffrey

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