-
Notifications
You must be signed in to change notification settings - Fork 81
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
[DRAFT] Using pyproject.toml and Cmake to build wheels #429
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @DiamonDinoia for putting this together. I've been reading up a bit on skbuild and cmake to try to understand what's going on here, but I still have a few questions.
One major one is how to structure this together with the two Python packages (finufft
and cufinufft
). Should we move this pyproject.toml
into python/finufft
and make another one in python/cufinufft
. I'm guessing this will mean changing some paths and setting cmake.source_dir = "../.."
or am I out of my depth here?
pyproject.toml
Outdated
# Setuptools-style build caching in a local directory | ||
build-dir = "build/{wheel_tag}" | ||
# Build stable ABI wheels for CPython 3.8+ | ||
wheel.py-api = "cp38" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this? Shouldn't we just leave it to the user (or the CI pipeline) to specify which ABI they want?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure it is necessary. Maybe for cross platform builds? The wheel is built using python 3.10 but we want it to work on previous versions too
pyproject.toml
Outdated
minimum-version = "0.4" | ||
cmake.targets = ["finufft"] | ||
cmake.args = ['-DFINUFFT_BUILD_PYTHON=ON', '-DCMAKE_BUILD_TYPE=Release'] # not sure if this is necessary | ||
wheel.packages = ["python/finufft/finufft"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this know to pick up the libfinufft.so
file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From:
install(TARGETS finufft LIBRARY DESTINATION finufft)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But doesn't that line tell cmake to install libfinufft.so in the python/finufft
directory (not the python/finufft/finufft
directory)? I guess it must be doing something else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So from what I understand, this is what skbuild does, essentially:
- Runs
cmake
andcmake --build
- Runs
cmake --install
to install the targets into some temporary directory (on my system, something like/tmp/tmpn4jdyywf/wheel/platlib
). - Copies the package in
wheels.packages
into that directory - Zips that directory up into a
.whl
file
So in our case, step 2 will install finufft/libfinufft.so
into that temp directory, while step 3 will copy python/finufft/finufft
there, which results in all the files living in the right places (so libfinufft.so
will be in the same directory as _finufft.py
and friends). This means that step 4 will put everything together into the desired wheel.
That is a solution. The only alternative I can think of is passing arguments to pip ( Feel free to make changes directly, here. |
So that would be like an extras-type install (
This is an issue with the current setup (pardon the pun) as well. Looks like
Just tried this locally and it seems to work (although it complains that it can't find |
Was able to get |
I've rebased on top of master to remove the conflicts. There's a backup branch called cpython_backup that's on my repo. Let me know if I've broken something here and I'll try to fix it. |
Great, thanks. There is only some change in python/finufft/finufft/_finufft.py breaks the master branch ci for python wheel builder using makefile. |
As I mentioned during the meeting, the wheel building for windows works… but it currently takes 76 minutes due to the constant rebuilding of FFTW. Some approaches I've tried to reduce this:
Another option would be to try to compile the latest FFTW from source using MSVC and installing it. This would allow |
I could make another Cmakelists in tools that install fftw only and we can make an action that makes that? Alternatively if we do @lu1and10, @janden do you think is sensible? I would personally build FFTW as the pre built might not have all the SIMD instructions enabled. |
Right I think this would make sense. Is it possible to do this in a way that the regular cmake file calls this, however? Would be nice to avoid having this FFTW installation code in two places.
Right, but this seems a bit hacky. This would avoid the duplication issue, though.
That's true, but doing the FFTW build in a separate step would also mean that we could cache the result and avoid having to build FFTW each time (similarly to how win and linux just download the library each time instead of building). |
What if we install fftw from the original tarball then? Instead of writing our own cmake-lists we could use the one they provide |
Of course. 🤦 This is what |
CPMAddPackage always build from source. One could use CPMFindPackage to use the system one first. I personally build my own way of checking if installed to allow the user to override FindPackage and be able to build it by hand. |
what is wrong with cmake/setup_FFTW.cmake ?
…On Mon, Jun 24, 2024 at 2:44 PM Marco Barbone ***@***.***> wrote:
What if we install fftw from the original tarball then? Instead of writing
our own cmake-lists we could use the one they provide
Of course. 🤦 This is what CPMAddPackage does under the hood, right? For
some reason I was thinking FFTW was using autoconf but now I see they have
cmake in there. Will give it a spin.
CPMAddPackage always build from source. One could use CPMFindPackage to
use the system one first. I personally build my own way of checking if
installed to allow the user to override FindPackage and be able to build it
by hand.
—
Reply to this email directly, view it on GitHub
<#429 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACNZRSWKYDUUE7DF5UEDCH3ZJBSJPAVCNFSM6AAAAABGLNHPZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBXGE4DQMZWG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
*-------------------------------------------------------------------~^`^~._.~'
|\ Alex Barnett Center for Computational Mathematics, Flatiron Institute
| \ http://users.flatironinstitute.org/~ahb 646-876-5942
|
Invoke-WebRequest -Uri "https://www.fftw.org/fftw-3.3.10.tar.gz" -OutFile "${{ github.workspace }}\fftw.tar.gz" | ||
|
||
New-Item -Path "${{ github.workspace }}" -Name "fftw-source" -ItemType Directory | ||
tar --strip-components=1 -C "${{ github.workspace }}\fftw-source" -zxf "${{ github.workspace }}\fftw.tar.gz" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you could do steps up to here on unix and save the result.
Then you can run cmake install on all OSs and cache the result. Maybe the env variable contains Path/OSs and they can all find the library somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you could do steps up to here on unix and save the result.
So to have a workflow job that just downloads the FFTW source and saves it somewhere? Sure. But as it is, the FFTW source is only needed by Windows (macOS and Ubuntu can install the library and headers via package managers). Or maybe I'm missing something here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is better to build fftw on all oses by hand as the package manager might ship a not vectorized version. I would like to have the fastest possible fftw bundled in finufft
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. We should be able to copy the recipe here (maybe after we clean up a bit) to ubuntu/macos.
This doesn't actually install FFTW, but looks for it on the system and if it doesn't find it downloads the source and “appends” it to the FINUFFT source (if I've understood things correctly). As it is, we can't just run After some wrangling with non-escaped backslashes, I've been able to get the Windows workflow to run. Although it looks like we have another conflict with master here that's preventing it from running on CI. |
Tried rebasing to resolve the conflict, but it seems a bit nasty. There's lots of thing happening around line 21 of CMakeLists.txt that needs some care. @DiamonDinoia From what I understand the changes in master are mostly from your PR, so maybe you can look at how to resolve this? |
Have a look. It should be okay now. |
Ok that makes sense. Just wanted to be sure. |
For some reason, these tests are failing because Python is unable to find the DLL. Should be fixable, but skipping tests for now.
Just did a force push after rebasing on top of latest master. |
Transter the metadata we had in setup.py.
Point the Python wheel building workflows to the new package directory in `python/finufft` instead of the repository root.
So this PR is now ready for merging. I've moved the pyproject.toml file into |
Hi @lu1and10,
I updated the python build system, changes:
Please, have a look!
Marco