Resolve PRIK through scikit-build-core's cmake.root - #69
Merged
Conversation
A scikit-build-core project had to include(UsePRIK), because cmake.module was the only entry point PRIK published. It now also publishes cmake.root, whose entry-point name scikit-build-core turns into a <name>_ROOT cache variable, so the name must stay PRIK: that is what lets a project listing PRIK in build-system.requires resolve find_package(PRIK CONFIG REQUIRED) with no PRIK_DIR, CMAKE_PREFIX_PATH, or CMAKE_MODULE_PATH. include(UsePRIK) keeps working through cmake.module, and PRIK_DIR, CMAKE_PREFIX_PATH, cmake-dir, and install-dir are unchanged. A configure-time structural query that cannot import PRIK or one of its dependencies now names the selected Python_EXECUTABLE and how to check it, keeping the underlying error. The hint is attached only to an import failure, so a real generation error still reaches the user as itself. prik doctor cmake reports what a build system would discover: the imported package, the metadata answering for it, cmake-dir, install-dir, both entry points, and any duplicate distribution, PYTHONPATH copy, or metadata that does not describe the imported package. The example defaults to find_package so its scikit-build-core route exercises the preferred form, and the primary regression test is now the end-user path: a fresh environment, build isolation on, PRIK reaching the build only through build-system.requires, then installing and calling the built extension. The existing --no-build-isolation route stays, since it builds against a checkout. Docs, CHANGELOG, packaging tests, and diagnostics tests are part of the same change, and the guide's prose covers all of it, so this lands as one commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KMz3kPhNruZUmNkDAMT9KJ
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
The example and the guide asked for scikit-build-core>=0.10, but cmake.root does not exist there: the entry-point group, its prefix_roots plumbing, and the <name>_ROOT cache entry all arrive in 0.11. A project pinned to 0.10.x would therefore configure without PRIK_ROOT and fail the documented find_package(PRIK CONFIG REQUIRED) route with no PRIK-specific -D flag. Both declarations now require scikit-build-core>=0.11, and the guide says why that is the floor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KMz3kPhNruZUmNkDAMT9KJ
saidctb
changed the title
The discovery section had grown into nine consecutive blocks, so the common path disappeared after the route table. The routes now split by the reader: "Configuring a project yourself" keeps PRIK_DIR against CMAKE_PREFIX_PATH and the install-dir record, while "Packaging and pinned interpreters" keeps scikit-build-core, the entry-point table, and asking a selected interpreter. Diagnosis gets its own heading rather than sitting under packaging, because a build that finds no PRIK, or the wrong one, is what sends a reader looking for prik doctor cmake from any route. The runnable example moves up beside the table it demonstrates. No fact changed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KMz3kPhNruZUmNkDAMT9KJ
The macOS lane failed the new test: scikit-build-core picked the default C compiler, Apple Clang, beside the job's Homebrew GNU Fortran, and the generated binding's #include <ISO_Fortran_binding.h> is only found beside the Fortran runtime that ships it. PRIK pairs the C driver with the Fortran vendor for that reason, which is why every other CMake test here names CMAKE_C_COMPILER. The test now passes the same pair through CMAKE_ARGS, the variable a build backend honours, and asserts no argument it sets names PRIK -- the claim under test is that PRIK needs no flag, not that CMake needs none. The guide states the constraint too, since a macOS reader with Homebrew GNU Fortran meets it before we do. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KMz3kPhNruZUmNkDAMT9KJ
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
1 participant
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.
No description provided.