Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions .github/workflows/nightly.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -24,16 +24,15 @@ on:
- cron: "0 6 * * *" # Every day at 06:00 UTC (00:00 CST)

jobs:
# allow_macos_failure: see pull_request.yaml's comment on the same input.
test_cmake_build:
uses: NWChemEx/.github/.github/workflows/test_nwx_cmake_build.yaml@master
with:
run_python_tests: "true"
cmake_opts: "-DINTEGRATION_TESTING=ON"
python_version: "3.12"
extra_pip_packages: "nwchemex"
allow_macos_failure: "true"

# allow_macos_failure: see pull_request.yaml's comment on the same input.
test_pip_build:
uses: NWChemEx/.github/.github/workflows/test_nwx_pip_build.yaml@master
with:
Expand Down
15 changes: 10 additions & 5 deletions .github/workflows/pull_request.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -29,19 +29,24 @@ jobs:
with:
doc_target: "scf_cxx_api"

# allow_macos_failure: SCF has a known, tracked, macOS-only segfault (see
# scf-macos-pybind11-segfault.md). macOS still runs and reports its real
# result -- visible signal for the investigation -- but doesn't block this
# workflow or PR merge readiness. Drop once the segfault is fixed.
test_cmake_build:
uses: NWChemEx/.github/.github/workflows/test_nwx_cmake_build.yaml@master
with:
run_python_tests: "true"
cmake_opts: "-DINTEGRATION_TESTING=ON"
python_version: "3.12"
extra_pip_packages: "nwchemex"
allow_macos_failure: "true"

# allow_macos_failure: test_pip_build's macOS gcc-14 leg has a separate,
# pre-existing, unrelated failure -- meson can't detect Homebrew gcc-14's
# linker on macOS ("Unable to detect linker for compiler `gcc-14
# -Wl,--version`": Homebrew's GCC uses Apple's native ld64 under the hood,
# not GNU ld, and meson's linker probe assumes GNU-compatible --version
# support for any gcc-family compiler) when building numpy from source
# (no cp314-compatible prebuilt wheel; see scf-macos-pybind11-segfault.md's
# original failure table -- this leg failed deterministically even before
# that investigation). Not the pybind11 segfault, not fixed by
# NWChemEx/.github#189. Drop once this is separately investigated/fixed.
test_pip_build:
uses: NWChemEx/.github/.github/workflows/test_nwx_pip_build.yaml@master
with:
Expand Down
23 changes: 16 additions & 7 deletions pyproject.toml
Original file line number Diff line number Diff line change
Expand Up @@ -19,13 +19,22 @@ requires = [
# gau2grid (fetched transitively via GauXC) invokes a Python codegen
# script at CMake configure/build time that imports numpy -- needed in
# the isolated build env even though scikit-build-core's build-system
# deps are otherwise C++-only. Capped below 2: newer numpy releases only
# ship manylinux2014 wheels for a GCC >= 10.3 build, and manylinux2014's
# own GCC 10.2.1 can't build numpy from source either, so an unpinned
# requirement falls back to a source build that fails outright. This
# cap only affects the isolated build env, not the runtime numpy version
# a user ends up with (see requirements.txt for that).
"numpy<2",
# deps are otherwise C++-only. Capped below 2 on Linux only: newer numpy
# releases only ship manylinux2014 wheels for a GCC >= 10.3 build, and
# manylinux2014's own GCC 10.2.1 can't build numpy from source either, so
# an unpinned requirement falls back to a source build that fails
# outright there. This cap only affects the isolated build env, not the
# runtime numpy version a user ends up with (see requirements.txt for
# that). macOS has no such manylinux/GCC-ABI constraint -- its wheel tags
# are keyed on the deployment target, not the build GCC -- so leaving it
# unpinned there lets pip resolve a real numpy>=2 wheel for whatever
# Python is active (e.g. cp314), instead of falling back to a numpy<2
# source build that has no cp314 wheel and fails distinctly: Homebrew's
# gcc-14 has no bundled linker, so it shells out to Apple's system ld,
# and meson's linker-detection probe (`gcc-14 -Wl,--version`) fails
# against it ("ld: unknown options: --version") on current macOS/Xcode.
"numpy<2 ; sys_platform == 'linux'",
"numpy ; sys_platform != 'linux'",
]
build-backend = "scikit_build_core.build"

Expand Down
Loading