Add libitk wrapping output#118
Conversation
Adds a `libitk-wrapping` output that includes the Python `itk` module (site-packages/itk and site-packages/itkConfig.py). Build turns on ITK_WRAP_PYTHON with ITK_USE_SYSTEM_CASTXML, identified by WRAP_ITK_INSTALL_COMPONENT_IDENTIFIER=PythonWrapping. ITK's wrapping install rules don't cleanly partition by COMPONENT, so: - libitk_install removes site-packages/itk* after its component sweep so the wrapping payload is not included in libitk. - libitk-wrapping_install sweeps all components into PREFIX then prunes to keep only the Python wrapping content. Bumps build.number to 5.
Includes Wrapping/, per-module wrapping/ subdirs, and build-tree Typedefs/ artifacts so external Python-wrapped modules can build against an installed ITK. libitk-devel also includes ITKModule*/KWStyle/Maintenance helpers required by ITKModuleExternal.cmake. Post-install patches WrappingConfigCommon.cmake to forward Eigen3 + module include dirs into the directory's INCLUDE_DIRECTORIES (read by ITK's wrapping/castxml pass).
ITK_WRAP_PYTHON=ON activates find_package(Python3 Development.Module), which
fails on aarch64/ppc64le because ${PYTHON} introspection yields BUILD x86_64
headers that CMAKE_FIND_ROOT_PATH=${PREFIX} filters out. Add explicit
Python3_INCLUDE_DIR + Python3_LIBRARY hints inside the existing cross-compile
block.
itk_auto_load_submodules.cmake demands CMAKE_CXX_COMPILER_TARGET so castxml (Clang-based) knows the target triple. Add inside the existing cross-compile block alongside the Python hints.
Castxml's bundled Clang can't parse PowerPC's __float128/__ieee128 builtin (in libstdc++ <limits>/<bits/specfun.h>) or Eigen's AltiVec PacketMath, so ITK_WRAP_PYTHON=ON fails at the castxml step on ppc64le. Disable wrapping for the linux-ppc64le target and skip the libitk-wrapping and libitk-wrapping-devel outputs on that platform.
|
Hi! This is the friendly automated conda-forge-linting service. I wanted to let you know that I linted all conda-recipes in your PR ( Here's what I've got... For recipe/meta.yaml:
For recipe/meta.yaml:
This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/26177234353. Examine the logs at this URL for more detail. |
|
Please consider updating the itk-feedstock where the current ITK python package is. |
Does it make sense to add an |
|
As far as I know ITK python requires static ITK libraries, while libitk provides share libraries to be reused by other packages. The compile time of the ITK libraries will be rather small compared to the wrapping. There appear to be several other libraries which depend on libitk: Addition: IMHO it would be ideal If the wrapping package would be an independent project which depended on the ITK shared libraries. That would require a MAJOR rework of the ITK wrapping code though. |
With the conda packages I have been testing, ITK Python seems to be working within the conda environment using shared ITK libraries. Could this be a Python wheel limitation?
I tried to be the least disruptive with the changes to the libitk and devel install scripts. Focusing on making just a wrapping bindings and wrapping source tree outputs. I wouldn't expect there to be any regression. If you still think these additions would be better suited for the itk-feedstock, I can move this over! |
|
Yes, please move this work to the irk-feedstock repo where the existing python wrapping is. |
3 participants
Checklist
0(if the version changed)conda-smithy(Use the phrase@conda-forge-admin, please rerenderin a comment in this PR for automated rerendering)Purpose
The purpose of this PR is to add a wrapping output to libitk conda packaging (discussed in ITKPythonPackage PR #302). This allows ITK remote modules to be packages as conda packages usable in Python conda environments.
I also experimented with using these conda packages as caches for building Python wheels for ITK. While this worked for mac and windows builds, to make manylinux compatible wheels, I believe the conda packages would need to be created within the manylinux docker environments with the correct compilers and toolchains (which may not be possible here).
Note
Only one Python version is built per platform variant.
Expanding to multiple Python versions (e.g. 3.10, 3.11, 3.12) is a follow-up decisions as it multiplies CI time, and the supported version set hasn't been agreed on yet.