Repository navigation
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The published wheels needed libObjCryst/libboost_python (Linux, macOS, Windows) from a conda environment: the old shared wheel workflow ran auditwheel and then removed the bundled libraries and pointed RPATH at the conda prefix. The nanobind build links ObjCryst++, cctbx and newmat statically and Boost is header-only, so build the wheels with cibuildwheel: - add [tool.cibuildwheel] (cp312-cp315; manylinux x86_64, macOS native, Windows AMD64; tests run on every wheel) - use the cibuildwheel shared workflow from SYMSCAE/release-scripts until it is released in scikit-package/release-scripts@v0 - derive the version from git tags with setuptools-scm instead of the static 2026.2.0rc0 placeholder - declare packaging as a runtime dependency (used by powderpattern) - trim unused ObjCryst++ submodule parts from the sdist - guard the GCC-only -O0 flag and add MSVC settings in CMakeLists.txt - ship the licenses of the statically linked code in the wheel Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@vincefn Please see if this looks good, I'll change the link and mark it ready once latest v0 is available. For your reference the generated wheels and test results (3.15) are here https://github.com/SYMSCAE/pyobjcryst/actions/runs/42438327523. |
|
LGTM - I did not have the time to test the wheels (leaving for a worshop in Beijing later today), though. |
|
@vincefn @sbillinge PR ready for review. |
sbillinge
left a comment
There was a problem hiding this comment.
please see inline comment.
| @@ -1,3 +1,4 @@ | |||
| setuptools | |||
| numpy | |||
| packaging | |||
There was a problem hiding this comment.
these seem to be all build tools. We normally use pip.txt for pip-specific installation packages to run the code, not to build it. I think we need to change the name of this to requirements/build.txt and put all the build stuff in there. Then you the workflows can pip install from build.txt
|
I looked at which compilation flags for numerical code this wheel would be built with. Only But it made me aware that previously, objcryst came from libobjcryst's scons build whose default I guess I want to ask: have we thought about which number-crunching compilation flags we want, and which ones we currently have? |
This PR makes
pyobjcrystuse the shared wheel-building workflow. Resolves #125.