[all-commits] [llvm/llvm-project] fe6d99: [mlir] Ability to build CAPI dylibs from out of tr...

[Stella Laurenzo via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fe6d9937b3846debfb2d97a32416064dc6c806e9
      https://github.com/llvm/llvm-project/commit/fe6d9937b3846debfb2d97a32416064dc6c806e9
  Author: Stella Laurenzo <stellaraccident at gmail.com>
  Date:   2021-10-13 (Wed, 13 Oct 2021)

  Changed paths:
    M mlir/cmake/modules/AddMLIR.cmake
    M mlir/cmake/modules/AddMLIRPython.cmake
    A mlir/examples/standalone/.gitignore
    A mlir/examples/standalone/include/Standalone-c/Dialects.h
    A mlir/examples/standalone/lib/CAPI/CMakeLists.txt
    A mlir/examples/standalone/lib/CAPI/Dialects.cpp
    M mlir/examples/standalone/lib/CMakeLists.txt
    A mlir/examples/standalone/test/CAPI/CMakeLists.txt
    A mlir/examples/standalone/test/CAPI/lit.local.cfg
    A mlir/examples/standalone/test/CAPI/standalone-capi-test.c
    M mlir/examples/standalone/test/CMakeLists.txt
    M mlir/examples/standalone/test/lit.cfg.py
    M mlir/test/Examples/standalone/test.toy

  Log Message:
  -----------
  [mlir] Ability to build CAPI dylibs from out of tree projects against installed LLVM.

* Incorporates a reworked version of D106419 (which I have closed but has comments on it).
* Extends the standalone example to include a minimal CAPI (for registering its dialect) and a test which, from out of tree, creates an aggregate dylib and links a little sample program against it. This will likely only work today in *static* MLIR builds (until the TypeID fiasco is finally put to bed). It should work on all platforms, though (including Windows - albeit I haven't tried this exact incarnation there).
* This is the biggest pre-requisite to being able to build out of tree MLIR Python-based projects from an installed MLIR/LLVM.
* I am rather nauseated by the CMake shenanigans I had to endure to get this working. The primary complexity, above and beyond the previous patch is because (with no reason given), it is impossible to export target properties that contain generator expressions... because, of course it isn't. In this case, the primary reason we use generator expressions on the individual embedded libraries is to support arbitrary ordering. Since that need doesn't apply to out of tree (which import everything via FindPackage at the outset), we fall back to a more imperative way of doing the same thing if we detect that the target was imported. Gross, but I don't expect it to need a lot of maintenance.
* There should be a relatively straight-forward path from here to rebase libMLIR.so on top of this facility and also make it include the CAPI.

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