New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update casacore to 3.1.1 and make less version needy #19
Conversation
bingo! https://cmake.org/cmake/help/v3.13/module/FindBoost.html
|
i've issued a PR with a fix upstream casacore/casacore#846 |
Boost 1.67 Python components require a Python version suffix. The logic for this was added to the CMake machinery of the upstream library in casacore/casacore#846, but this won't make it into a release for a while. Add a patch in the meantime, to be removed on the next release.
we also need to make sure
|
ah you already do that. @ludwigschwardt you are my hero. |
I aim to please! |
Anything more here? What about I guess it's picking up the system Python (associated with the default command |
yes, we need to make sure that is overwritten in the recipe |
I'm busy extending this branch to catch up with the latest changes... |
The wcslib formula moved back to homebrew/core in July 2018 after brewsci grew stale. The boost-python library for Python 3 has a separate formula since 1.66.0 (Feb 2018). Restore gcc dependency since casacore looks for a Fortran compiler during cmake configure. Since casacore 3.0 it is now mandatory to use C++11 features (see casacore/casacore#580). Also ensure that undefined symbols are ignored until runtime in the Python shared library.
Only apply the patch to current releases (3.0 and 3.1). The HEAD and future 3.2 release already has it (due to casacore/casacore#846).
These provide more robust detection of Python versions on macOS and replace the functionality of casacore's FindPython.cmake and FindNUMPY.cmake. Previously the Homebrew Python 3 include dirs were confused with those of Homebrew Python 2. There is also no need to hardcode the Python executable and library (always a bad idea). While these modules are available since cmake 3.12, they could be copied to casacore and still run on cmake 3.7, in case the bigger project has need of them.
The stable patch turns v3.0.0 into c349f27, effectively applying #846. The original patch only included the first commit of this PR (d'oh). The cmake patch now applies on top of #846 and also works on the latest HEAD.
The boost-python3 formula has no --with-python option (that sounds tautological anyway).
Use latest stable version from GitHub.
Follow the "Python for Formula Authors" document, which states that 'Python 2 libraries do not need a depends_on "python@2" declaration; they will be built with the system Python, but should still be usable with any other Python 2.7.' Thereby make the optional python@2 support mandatory, since system Python 2.7 is always available.
This currently does v3.1.0 fine but I suspect HEAD is broken. Should we merge this so long and open another PR once 3.1.1 comes out? That would probably allow me to get rid of the patches in that PR. |
The HEAD no longer needs a patch (although it is currently running off a feature branch to be merged as casacore/casacore#922). Now use a single patch that turns v3.1.0 into HEAD (at least as far as the Python build scripts are concerned).
The HEAD support now works again (based off casacore/casacore#922). |
@gijzelaerr, if we can get casacore/casacore#922 merged in time for the 3.1.1 release, I can remove all the patches in this formula... 😉 |
Thanks to casacore/casacore#922 we can also drop all the patches.
This works on my laptop with no patches now... Happy to merge if you are. |
unfortunately this still can't find the new boost python.
a minimal
CMakeLists.txt
like:still gives:
with
cmake 3.13.1
and boost1.68.0
while it looks like this bug has been fixed sincecmake 3.11.0
https://gitlab.kitware.com/cmake/cmake/commit/1673923c303c6a4184904c4c5849911feddb87e7