[Mlir-commits] [mlir] [mlir][Python] Generate type stubs for dialect extensions (PR #236657)

[llvmlistbot at llvm.org]

================
@@ -598,6 +636,32 @@ function(add_mlir_python_modules name)
     _process_target(${name} ${sources_target} "${_mlir_python_support_libs}")
   endforeach()
 
+  if(MLIR_PYTHON_STUBGEN_ENABLED)
+    # Import package initializers only after its native extensions and Python
+    # sources are ready. Depend on concrete targets, not the package aggregate:
+    # the latter also depends on the generated stubs and would form a cycle.
+    set(_stubgen_inputs ${ARG_STUBGEN_DEPENDS_TARGETS})
+    foreach(sources_target ${_flat_targets})
+      get_target_property(_source_type ${sources_target} mlir_python_SOURCES_TYPE)
+      if(_source_type STREQUAL "extension")
+        get_target_property(_module_name ${sources_target} mlir_python_EXTENSION_MODULE_NAME)
+        list(APPEND _stubgen_inputs "${name}.extension.${_module_name}.dso")
+      elseif(_source_type STREQUAL "pure")
+        list(APPEND _stubgen_inputs "${name}.sources.${sources_target}")
----------------
PragmaTwice wrote:

>From agent: Stubgen imports the fully qualified extension module, which runs the package initializers. The dialect adaptors also import "<package>.ir", so those Python files need to be ready first. The old "_mlirPythonTestNanobind" rule already depended on "MLIRPythonSources.Core.Python" for this reason. Depending on all pure-source targets is conservative, though.

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