Enhance Windows compatibility and update CI configurations

[hkmoon]

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:

• Added a new GitHub Actions 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:

• Updated CMake modules (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]
• Modified core/CMakeLists.txt to 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:

• Added a detailed CHANGELOG.md documenting recent changes, release preparations, and platform-specific notes, including new contributor acknowledgments.
• Updated the README.md with clear installation instructions for Linux, macOS, and Windows, and clarified wheel/platform support.

CMake Modernization and Refactoring:

• Refactored the top-level CMakeLists.txt to use modern CMake practices, improved project metadata, integrated jrl-cmakemodules for streamlined dependency management, and added options for documentation and testing.
• Temporarily disabled the addition of the python subdirectory 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.

[ofloveandhate]

I really like the documentation! I have a few notes about the Python docs:

• I had previously used gitpython to write the git commit into the Sphinx-generated docs. Is that still working? Is there a better way to do it?
• From the version I looked at on your repo, the library either wasn't built or wasn't importable when the docs were generated, so the classes and functions are lacking their autodocs. The only things that appear are the contents from the .rst files. When I was working on them last week on my mac, I had to adjust the pythonpath to pick up the build directory I was using. I think that's probably the fix?

[hkmoon]

• I had previously used gitpython to write the git commit into the Sphinx-generated docs. Is that still working? Is there a better way to do it?

Yes, gitpython is used for Sphinx configuration. The docs are updated.

• From the version I looked at on your repo, the library either wasn't built or wasn't importable when the docs were generated, so the classes and functions are lacking their autodocs. The only things that appear are the contents from the .rst files. When I was working on them last week on my mac, I had to adjust the pythonpath to pick up the build directory I was using. I think that's probably the fix?

Can you check it if it's working? I am currently working on docs branch that will be merged into develop when you confirm it.

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.

[ofloveandhate]

Hi! Thanks!!! I just want to be cautious: We shouldn't be using actual PyPI for development work through this PR... we should be using testpypi for this, until we get it all dialed in and make a release. Then releases should trigger to PyPI. But I'll still give it a try.

[hkmoon]

@ofloveandhate Sure, you can manage the releases and versions. I wound't touch it anymore. You can also delete the current release in PyPI too. Let me know when all the things are merged into develop/main. Then, I will check all the information and documentation links are properly updated. Thanks a lot!

[ofloveandhate]

Ok! So I think this remains before merging: (we're so close!)

• adjust the workflow to only publish to pypi from main (it already only procs with version tags)
• documentation changes
• update build instructions. find and destroy all out of date build and install instructions
• in doc_resources/landing/index.html, change to the url to bertiniteam, not hkmoon

and this will be done after I accept:

• point my domain to the github pages for this repo
• change default branch to main

[ofloveandhate]

more todos:

• make bertini2 project on test/pypi, so that people are absolutely clear that they're not installing bertini 1.
• delete the old un-qualified bertini project on test/pypi