forked from OSchip/llvm-project
2607209b3f
libMLIRPublicAPI.so came into existence early when the Python and C-API were being co-developed because the Python extensions need a single DSO which exports the C-API to link against. It really should never have been exported as a mondo library in the first place, which has caused no end of problems in different linking modes, etc (i.e. the CAPI tests depended on it). This patch does a mechanical move that: * Makes the C-API tests link directly to their respective libraries. * Creates a libMLIRPythonCAPI as part of the Python bindings which assemble to exact DSO that they need. This has the effect that the C-API is no longer monolithic and can be subset and used piecemeal in a modular fashion, which is necessary for downstreams to only pay for what they use. There are additional, more fundamental changes planned for how the Python API is assembled which should make it more out of tree friendly, but this minimal first step is necessary to break the fragile dependency between the C-API and Python API. Downstream actions required: * If using the C-API and linking against MLIRPublicAPI, you must instead link against its constituent components. As a reference, the Python API dependencies are in lib/Bindings/Python/CMakeLists.txt and approximate the full set of dependencies available. * If you have a Python API project that was previously linking against MLIRPublicAPI (i.e. to add its own C-API DSO), you will want to `s/MLIRPublicAPI/MLIRPythonCAPI/` and all should be as it was. There are larger changes coming in this area but this part is incremental. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D106369 |
||
|---|---|---|
| .. | ||
| AddMLIR.cmake | ||
| AddMLIRPython.cmake | ||
| CMakeLists.txt | ||
| MLIRConfig.cmake.in | ||
| MLIRDetectPythonEnv.cmake | ||