-
-
Notifications
You must be signed in to change notification settings - Fork 46
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
FEAT: Transition to scikit-build-core CMake-based build process #162
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #162 +/- ##
==========================================
- Coverage 85.68% 84.64% -1.05%
==========================================
Files 11 12 +1
Lines 566 573 +7
Branches 67 68 +1
==========================================
Hits 485 485
- Misses 45 52 +7
Partials 36 36
|
…cikit-cmake # Conflicts: # setup_tools/build_clib.py # setup_tools/support.py
@ofek So this is a |
Henry (the maintainer) is working on making a plugin for Hatchling. Until then this current approach is fine. Which PR should I review? I don't quite know the plan. |
#159 is ready, it only add verification for shared lib build. Or do you think it should not be added? |
This PR still has issues, but I think it is more maintainable than the setuptools+CMake. Also, I had not realized that you know so much more than me on this subject (looking at how hatch is written), so I admit I am myself a bit confused as to your plans for Do we need to better sync-up? |
Definitely please move forward just with scikit-build-core! |
So, if I undersand correctly, Henry will build a plugin for hatch which would use scikit-build-core and be able to interact with hatch, but I think what I thought we would have is a hatch plugin to interact/control scikit-build-core. I am trying to update the config with something like:
to try to understand how hatch fits/improves the current status |
The plugin would live at the build system layer i.e. Hatchling, which would invoke some logic within that other package. Hatch the CLI has nothing to do with this and we don't even have to use it if you don't want to. |
With
content:
When I install that wheel and test it, it seems to work Note that I could be missing something quite obvious |
pyproject.toml
Outdated
'scikit-build-core>=0.9.0', | ||
'hatchling', | ||
'setuptools>=42.0.0', | ||
'cffi>=1.3.0, |
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.
'cffi>=1.3.0, | |
'cffi>=1.3.0', |
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.
Right, Thanks, I got this one and corrected it at my end, but realized the tox
test did not pass at my end either (I was using python -m build
), so I stopped committing failing updates to minimize the emails
I'd recommend pushing the update so we can see the final failure message. Also if the wheel looks fine I don't quite understand what you mean about tox not working correctly. Could it be that editable installations aren't yet supported so we should remove that option in tox? |
@ofek that was it! Pushing thru |
Ready for review? |
Yes, it is ready - I got distracted with other projects - I am not very knowledgeable in CMake, so there maybe lots of improvements possible |
@ofek Did you have some time to review? Perhaps finding someone knowledgeable in CMake to provide feedback would be good |
Sorry for the wait! I just tried and am getting an error:
|
No pkg-config it looks like. |
I wonder if there’s a way we can suppress those extra tracebacks that aren’t useful. |
I was expecting it to Just Work ™️ ... is that a requirement? |
Co-authored-by: Ofek Lev <[email protected]>
Can we drop Windows 32 bit? After that CI will pass (no |
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.
This is awesome, thank you very much!
Please keep in mind that I will need assistance maintaining this because, although it's much better than before, I have no idea how any of this works... at all 😅 For example, it's unclear to me why we have multiple top-level directories, a script that does stuff to the header files and another for something else.
Well, that organization is just a matter of preference (or non-formal CS background) it could be organized differently. I am also not very knowledgeable with CMake, so I needed a lot of debugging, separating the different phase helped me navigate |
This was initally started to transition to Hatchling. However, as I learned more about
scikit-build-core
, it seems that it handles all the steps required to buildcoincurve
. However, I do not know Hatchling, so let me know your thoughts on how we should integate it.This PR itself changes some of the original features of coincurve. CMake provides a convenient way to download the SECP256K1 library, so currently, I did not add this feature (though the current UPSTREAM_REF is used)
The other major addition is that the flow creates the CFFI source headers directly from the downloaded SECP256K1 original headers, so it should be quite straightforward to follow SECP256K1 updates.
The rest is fairly similar, create the SECP256K1 library (using the CMake they provide), create the CFFI C-code (rather than compile it with CFFI), then compile the C-Code and link it to SECP256K1 library.
The feature of using SYSTEM_LIB is similar, although I have not tested it as well as for the CMake-based PR.