- Uses this to build an aggregate of the MLIR C-API, as required by the Python bindings.
- Should be extensible to cover the libMLIR use cases with some more work, but check pointing on this simple form to start (it has fewer requirements and low potential to break anyone).
- I think that if this proves successful for MLIR, we may want to make a case to promote it to LLVM and use it to replace the current component system.
- Should allow for both static and shared linkage of aggregate libraries, as well as optionality in terms of what goes in them (while also being correct and not causing ODR issues in expected usage).
- Intended to be a piece to be used both in and out of tree, specifically for projects like npcomp and circt which need to instantiate their own Python and aggregate C-APIs.
Details
- Reviewers
stephenneuendorffer mehdi_amini
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/cmake/modules/AddMLIR.cmake | ||
---|---|---|
57 | IS the intention to deprecate usage of EXCLUDE_FROM_LIBMLIR in favor of DISABLE_AGGREGATE? | |
237–240 | Do you mean to check in this debugging code? I don't think it's a bad thing, just asking :) | |
mlir/lib/Bindings/Python/CMakeLists.txt | ||
13 | It's not clear to me how targets depend on this. Do they depend on MLIRPythonCAPI directly? or do they depend on a contained library, like MLIRCAPIGPU? | |
16 | spacing instead of tabs? |
Generally speaking I like this approach... It's much simpler than the alternatives that I've seen. I think we should try to take it to the next step....
mlir/cmake/modules/AddMLIR.cmake | ||
---|---|---|
176 | Should this be a generator expression as well? |
Can you document the new flag?