-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Description
Since the work last year to refactor how MLIR Python extensions are linked, we have had this comment about dis-aggregating MLIRPythonExtension.Core:
llvm-project/mlir/python/CMakeLists.txt
Line 279 in 6ccc273
MLIRCAPIRegistration # TODO: See about dis-aggregating |
My understanding is this dependency on MLIRCAPIRegistration is pulling in all the MLIR dialects, translations, and conversions:
llvm-project/mlir/lib/CAPI/Registration/CMakeLists.txt
Lines 1 to 14 in 10affe7
# Dialect registration. | |
get_property(dialect_libs GLOBAL PROPERTY MLIR_DIALECT_LIBS) | |
get_property(translation_libs GLOBAL PROPERTY MLIR_TRANSLATION_LIBS) | |
get_property(conversion_libs GLOBAL PROPERTY MLIR_CONVERSION_LIBS) | |
add_mlir_upstream_c_api_library(MLIRCAPIRegistration | |
Registration.cpp | |
LINK_LIBS PUBLIC | |
MLIRCAPIIR | |
MLIRLLVMToLLVMIRTranslation | |
${dialect_libs} | |
${translation_libs} | |
${conversion_libs} | |
) |
Some downstream projects may not want all of that, and may just want to depend on the "core" MLIR Python extension. This is definitely the case in the CIRCT project.
I wanted to open an issue before diving in to see if anyone has thoughts about how to go about this.