[Mlir-commits] [mlir] [MLIR][Python] Extend bindings for external projects without duplication (PR #173241)

[Maksim Levental]

makslevental wrote:

> Ok thanks. I though having distinct `DECLARED_SOURCES` in `add_mlir_python_common_capi_library` for `MLIRPythonCAPI` and `MYPROJECTPythonCAPI` + dynamic linking + no duplication of any Python file would be enough (And it works on our compiler with a Transform dialect + MLIR + LLVMIR pipeline).

There's no way you're actually doing this successfully because you need to link [`MLIRCAPIR`](https://github.com/llvm/llvm-project/blob/main/mlir/lib/CAPI/IR/CMakeLists.txt#L2) for your downstream dialects to work correctly (e.g., register successfully). So your `SDistPythonCAPI` has at least this in common with `MLIRPythonCAPI`. You can figure out what it really has in it by looking at the link line in `build.ninja`.

> So if I want to build let's say `mlir_sdist`, `mlir_aie` and upstream to make them work together, if I'm correct I need to create a mega package that build everything together, and name it `mlir` to prevent the replacement of all imports using it 😢.

You don't need to do that - you can do `cd mlir_aie/build && ninja install` i.e., make an install distro of their project. That particular project I know that will work (because I set it up to work so that their wheels could be built). Then you use that distro in your project and you have all of their CMake targets available.

But generally people don't do this - generally people have an arrow going from `mlir_aie` -> `mlir_sdist` (or the other way around) and they "cross the boundary" between the two projects/packages by serializing the module (`src = str(module)`) and then de-serializing it (`Module.parse(src)`).



https://github.com/llvm/llvm-project/pull/173241