Enhance Windows compatibility and update CI configurations#212
Open
hkmoon wants to merge 238 commits intobertiniteam:developfrom
Open
Enhance Windows compatibility and update CI configurations#212hkmoon wants to merge 238 commits intobertiniteam:developfrom
hkmoon wants to merge 238 commits intobertiniteam:developfrom
Conversation
There are some compiling errors while being compiled in windows * `size_t` is translated into `unsigned long` in linux, mac while `unsigned long long` in windows 10: `core/include/bertini2/eigen_extensions.hpp` and `core/test/classes/start_system_test.cpp` are modified * use `clang` of LLVM in Windows since MSVC has different compiling way for `template` * use `--no-isolation` for `scikit-build` in Windows For linux wheel naming convention, we cannot use x86_64, x86_i386 anymore for pypi repository. https://peps.python.org/pep-0600/ * use `auditwheel` for it Co-authored-by: HongKee Moon <moon@mpi-cbg.de>
the default branch is changed to 'develop'
additionally, fix ctest folder
additionally, fix ctest folder
* chore: test for win32 * chore: use Release libraries for linking in windows * chore: use 1e-14 instead of 1e-15 * 1e-15 doesn't work in windows * chore: remove docker-compose.yml * chore: revert test list --------- Co-authored-by: HongKee Moon <moon@mpi-cbg.de>
…d calls due to windows test error In windows, x.precision is considered as a bound method which is not callable. Therefore, x.precision() is changed to return integer value.
Boost.Python is ABI-locked to a single CPython version. The previous CIBW_BEFORE_ALL_LINUX built it once against the manylinux2014 system python3 (3.9), so every wheel — cp39 through cp313 — bundled the same libboost_python39.so. cp310/cp311/cp312/cp313 imports failed at module init with "SystemError: initialization of _pybertini failed without raising an exception". Move the Boost + eigenpy build into CIBW_BEFORE_BUILD_LINUX so it runs once per target Python against $(which python). BEFORE_ALL is reduced to yum install + tarball downloads to /tmp.
Same ABI mismatch as the Linux fix. Homebrew's boost-python3 / eigenpy bottles track the current Homebrew default Python (now 3.14), so a cp313 wheel built against them ships libboost_python314.dylib and segfaults at import in a 3.13 interpreter (Fatal Python error: SIGSEGV). Restore the per-Python source build of Boost.Python + eigenpy that the workflow used pre-1f3dccf6, mirroring the Linux structure: brew install the version-independent libs (gmp/mpfr/libmpc/eigen@3) plus tarball downloads in BEFORE_ALL_MACOS, then build Boost+eigenpy into /tmp/deps-py per target Python in BEFORE_BUILD_MACOS.
Now that Boost.Python and eigenpy are rebuilt per target Python in
BEFORE_BUILD_MACOS, the macOS path can produce wheels for the same
Python matrix as Linux instead of just cp313. Test matrix is
collapsed back to a cross-product of {ubuntu-latest, macos-14} ×
{3.9..3.13}.
eigenpy's CMake calls find_scipy() unconditionally from
unittest/CMakeLists.txt, even with -DBUILD_TESTING=OFF, and aborts
configure with "Failed to detect scipy". The pre-1f3dccf6 workflow
installed scipy alongside numpy; restore that in BEFORE_BUILD_{LINUX,MACOS}.
scipy stopped shipping manylinux_2_17 wheels in 1.14, so the per-Python 'pip install scipy' (needed for eigenpy's find_scipy at configure time) fell back to source-building scipy on cp310/311/312/313 inside the manylinux2014 container and failed on missing OpenBLAS. manylinux_2_28 (glibc 2.28, AlmaLinux 8 base) has scipy binary wheels for cp39–cp313. Tradeoff: produced wheels require glibc 2.28+ (Ubuntu 18.04+, RHEL/CentOS 8+, Debian 10+) instead of 2.17.
a74ca56 added --no-index to the wheel install, which is the right intent (force the local wheel) but blocks pip from reaching PyPI for the transitive numpy dependency: "No matching distribution found for numpy". Install numpy from PyPI first, then bertini offline from dist/.
Ensure thread default precision matches static default precision for Boost.Multiprecision.
…ructors With init<long int> on line 371 still in place plus IMPLICITLY_CONVERTIBLE(int, T) registered later in ExposeFloat, Float(123) will still resolve cleanly.
Contributor
|
I really like the documentation! I have a few notes about the Python docs:
|
Author
Yes,
Can you check it if it's working? I am currently working on The current url is based on github.com/hkmoon, which should be replaced by b2 when the PR is merged. By the way, Bertini version is 2.0.0 in PyPI. Please check it when you have time. |
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.
This pull request introduces significant improvements to the build system and release workflow for the project, especially focusing on cross-platform compatibility and automated Python package publishing. The main highlights include the addition of a comprehensive GitHub Actions workflow for building and publishing Python wheels to PyPI/TestPyPI, enhancements for Windows compatibility, and updates to documentation and changelogs to reflect these changes.
Automated Build and Release Workflow:
.github/workflows/build-and-publish-to-pypi.yml) to automate building Python wheels for Linux, macOS, and Windows, and to publish them to PyPI, TestPyPI, and GitHub Releases. This workflow includes environment setup, dependency installation, platform-specific build steps, artifact uploading, and release signing.Windows Compatibility Improvements:
cmake/FindGMP.cmake,cmake/FindMPFR.cmake,cmake/FindMPC.cmake) to correctly locate and link against Windows-specific library filenames, improving build reliability on Windows. [1] [2] [3]core/CMakeLists.txtto set appropriate build flags and shared library options for MSVC, and improved Boost/Eigen3 detection and linking for cross-platform builds. [1] [2] [3] [4]Documentation and Changelog Updates:
CHANGELOG.mddocumenting recent changes, release preparations, and platform-specific notes, including new contributor acknowledgments.README.mdwith clear installation instructions for Linux, macOS, and Windows, and clarified wheel/platform support.CMake Modernization and Refactoring:
CMakeLists.txtto use modern CMake practices, improved project metadata, integratedjrl-cmakemodulesfor streamlined dependency management, and added options for documentation and testing.pythonsubdirectory in the build to avoid issues during the transition.These changes collectively streamline the build, test, and release process, making it easier to maintain and distribute the package across all major platforms.
References:
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
Check the github workflow: https://github.com/hkmoon/b2/actions/runs/23671693162
Use https://pypi.org/manage/project/pybertini/release/1.0.9/ for testing.