Repository navigation
vtk: publish the VTK_INSTALL_SDK=ON include/cmake tree as a build artifact - #3312
Merged
Merged
Conversation
…tifact VTK_INSTALL_SDK=ON is already set, and cmake --build /build --target install already writes a full include/ tree plus the generated vtk-config.cmake package files to /build/install - but build-vtk.yml only ever packaged vtkmodules/*.so into the published wheel, so none of that SDK output ever left the runner. This blocks the cadquery-ocp port, whose CMake needs find_package(VTK) headers on riscv64 (see .queue.yml's cadquery-ocp entry). Additive only: packages the already-installed include/ and vtk-config.cmake directories from the cp312 leg (module-identical to cp313/cp314; cp314t disables IONetCDF and isn't a cadquery-ocp target anyway) into a tarball and uploads it as its own vtk-<version>-sdk artifact, alongside the existing per-interpreter wheel artifacts and without touching how they're built or published. No new compute: this is a pure repackaging of install output the build step already produces. A plain GitHub Actions artifact (90-day retention) rather than a second published wheel: _publish-wheel.yml's durable GitHub Release path is wired for wheels (+ one GPL-sources tarball) only, and widening it is a shared-workflow change out of scope for a single-package fix.
luhenry
added a commit
that referenced
this pull request
Oct 15, 2026
build-vtk.yml (PR #3312) captures VTK_INSTALL_SDK=ON's already-produced include/ and vtk-config.cmake tree as a standalone artifact for cadquery-ocp rather than rebuilding anything, picking one representative matrix leg when the module set isn't identical across the matrix, and favoring a continue-on-error GitHub Actions artifact over widening the shared _publish-wheel.yml release path for a single package. Recorded in native-deps-and-linking.md for reuse by future similar cases.
luhenry
added a commit
that referenced
this pull request
Oct 15, 2026
…, not yet produced an artifact)
luhenry
marked this pull request as ready for review
October 15, 2026 13:07
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Not a version bump - modifies the already-published
vtkbuild itself.cadquery-ocp's queue entry is blocked on a riscv64 VTK SDK:build-vtk.ymlalready configures-DVTK_INSTALL_SDK=ONand runscmake --build /build --target install, which already writesinclude/plus the generatedvtk-config.cmakepackage files to/build/install- but the workflow only ever packagesvtkmodules/*.sointo the published wheel, so that install output never left the runner. No riscv64 vtk SDK exists anywhere else (not on conda-forge, not on PyPI).Change: two new steps in
build_wheels, gated onmatrix.python == 'cp312'(module set is identical across cp312/cp313/cp314; only cp314t additionally disablesIONetCDF, and it isn't a cadquery-ocp target). They tar up the already-installedinclude/tree and whichever directoryfindlocatesvtk-config.cmakein (handleslibvslib64), andupload-artifactthe result asvtk-<version>-sdk, separate from the existing per-interpreter wheel artifacts. No new compute - pure repackaging of install output the build already produces.Differs from upstream: n/a (this is additive to our own workflow, not a new build shape).
Why an artifact, not a second wheel: this repo does have a "ship C++ headers separately" precedent (
tbb-devel), but it publishes its own wheel through_publish-wheel.yml's GitHub Release path. That path is wired for wheels (+ one GPL-sources tarball) only; widening it to a non-wheel SDK tarball is a shared-workflow change affecting every package, out of scope here. A plain artifact (retention-days: 90) is the conservative, in-scope option - cadquery-ocp isn't ready to consume it yet anyway.Risk / validation caveat:
docs/packages/vtk.yamlhas no pending version, so_setup.ymlresolvesversionsto[]on this PR andbuild_wheels(and therefore these two new steps) does not run at all on this PR's own CI - a green check here only proves the YAML parses, not that the packaging logic works. Both new steps carrycontinue-on-error: trueso that if anything about them is wrong, they cannot fail the job or block a future version's real wheel publish. Verified thefind/cp -a/tarlogic separately against a fabricated directory tree (bothlibandlib64cmake layouts) outside CI. Real validation only happens the next time a newvtkversion is queued and goes through the normalpush-to-mainbuild, or via an explicit maintainer-triggeredworkflow_dispatchrebuild of an existing version (full ~15-20h build per leg, so not done preemptively here). Left as draft for that reason - flip to ready whenever that validation is convenient.Testing: n/a (SDK step is best-effort/non-blocking; existing wheel build/test steps are untouched).
License: n/a (no change to what ships in the wheel).