Closed JamesTheAwesomeDude closed 4 months ago
Related to, but slightly distinct from, Issue #4
*This* issue resolves when we get BUILT WHEELS; *that* issue resolves when we get the upstream test files linked into some Python test suite.
(These may or may not be resolved with the same action; I don't care either way.)
TLDR(yet): thingamajig build wheel, wheel ship to user, user make wagon.
So we use this to get A Computer (I'm not so concerned with self-hosting this, at least at first) to build a "wheel" artifact, which is the Thing that gets installed by pip a-la .deb/.rpm files.
Are we also hoping to publish to PyPy? (I assume yes?)
We're already on PyPI, though with an "sdist-only" release, meaning right now anyone who tries to pip install pypqc
will end up installing it if and only if they already have all the system-level build dependencies, which are: (a) a C compiler, (b) the Python headers, (c) libffi
, if on MacOS.
Getting "wheels" will allow people without build toolchains to install the package, indeed.
(*Not PyPy; that's colloquially "the only maintained non-CPython Python implementation", which boasts much greater performance for certain workloads)
get A Computer (I'm not so concerned with self-hosting this, at least at first) to build a "wheel" artifact,
The big annoyance with GitHub Actions is that they seem to require modifying your source tree in arguably ugly ways.
I think (despite the documentation) cibuildwheel doesn't have to be run as a CI tool; you can just run it ad-hoc on release commits, and still get the advantages: linking against a maximally compatible libc
, building for multiple OSes at once, having pre-rizzed buildchains that do nice things like auditwheel (which I think PyPI rejects "bdist" packages without, anyway?) that expand the wheels' compatibility even further, etc.
Dang, that compatibility chart has some mighty holes, actually...
https://cibuildwheel.readthedocs.io/en/stable/#usage
I can't tell how much of a nightmare my previous claim of running cibuildwheel baremetal would actually be to implement. Maybe GH Actions it is, for now...
FWIW, I think it might be better to start with Issue #4 first, that way the CI starts providing canary value right away, rather than only being "someone else's compiler" from the beginning
I don't know whether CFFI, cibuildwheel, PQClean, Github, or myself is to blame here, but when I tried to configure a Github Action for this, it's choking on -Wimplicit-function-declaration
https://github.com/JamesTheAwesomeDude/pypqc/actions/runs/7672837625/job/20914216091#step:5:423
(It cancelled all the runs when the OSX run failed; I guess that's the default behavior of matrix
, though probably not a problem in this case since that error will likely be the same across all platforms.)
It cancelled all the runs when the OSX run failed ... probably not a problem in this case since that error will likely be the same across all platforms
Well, you know what they say about assuming...
https://www.google.com/search?q=cibuildwheel+%22-Wimplicit-function-declaration%22
looks like this is a nearly OSX-exclusive issue
I don't know why the current cffi_modules
are raising compiler warnings. I think more header files need to be included; the problem is that upstream's Makefiles are hella inconsistent.
Also, I cannot figure out how to get CFFI not to inject -Werror
on Mac OS. Not sure whether cffi, setuptools, wheel, cibuildwheel, or someone else is to blame...
EDIT: found it—https://github.com/actions/runner-images/issues/1938
Thank GOD (and ask his forgiveness for this also), -Wno-error=implicit-function-declaration
has stepped in to save the day; CI for the Apple Folk is functioning
https://github.com/JamesTheAwesomeDude/pypqc/actions/runs/7719777061
https://cibuildwheel.readthedocs.io/
We NEED it
it is GOOD
(But see if it can be implemented self-hosted, maybe? without putting weird gobs of Microsoft Gunk in the source tree?)