Repository navigation
fix(make): drop the install recipe whose OpenSSL flags never applied - #972
Merged
Merged
Conversation
make expanded $(brew --prefix) to an empty string, each export ran in its own shell, and a double-colon install:: recipe cannot pass environment to python.mk's uv sync anyway. cryptography and granian install from macOS arm64 wheels, and the one cp314 sdist build (watchdog) links CoreServices, not OpenSSL. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
What
Deletes the
install::target at the top ofcfg/codex.mk. It was supposed to point macOS wheel builds at Homebrew's OpenSSL.Why
None of its lines ever reached python.mk's
uv sync:$(brew --prefix)is expanded by make, not the shell, so the prefix was always empty.make -n installshowedBREW_PREFIX=and paths like-L/opt/openssl@3/lib.exports ended with it.installis a double-colon target, so eachinstall::recipe is a separate rule, and not even.ONESHELLcould carry the exports intocfg/python.mk'suv sync.make installhas kept working anyway, because nothing needs the flags:uv sync --no-install-project --all-extras --all-groups --all-packages --reinstall-package cryptography --reinstall-package granian -vinstalls both from PyPI macOS arm64 wheels, with noBuildingorBuiltlines.uv.lock:watchdog6.0.0 is the only one that builds from source on cp314, and its extension links CoreServices, not OpenSSL. The other packages that ship only an sdist are pure Python.Reviewer notes
cfg/codex.mkbelongs to codex, somake update-devenvwon't bring the target back.exports inside anifeq ($(shell uname -s),Darwin)block, not in a recipe.Verification
make -n installno longer prints the four lines, andmake installexits 0.make fixmakes no other changes.make lintpasses, and mbake reportscfg/codex.mkvalid.make helpstill lists the Install category, minus "Configure wheel building for Darwin".make test: 984 vitest and 1662 pytest passed, 1 xfailed.🤖 Generated with Claude Code