Title: Tag libffi build and sources in cpython-source-deps for 3.9.0b1
Type: enhancement Stage:
Components: Build, Windows Versions: Python 3.9
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: indygreg, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2020-04-15 15:02 by indygreg, last changed 2020-04-15 18:13 by steve.dower.

Messages (5)
msg366523 - (view) Author: Gregory Szorc (indygreg) * Date: 2020-04-15 15:02
The project is missing a source archive release for commits to libffi needed to support building on Windows.

The latest release of libffi is version libffi-3.3.0-rc0-r1, which corresponds to

There have been a few commits since that release:

Most notable is because without this commit, the source is not buildable on Windows using MSVC, at least not with the  prepare_ffi.bat script in CPython's Git repository. (Build fails due to issues with FFI_BUILDING_DLL).

Would it be possible to cut a new tag and upload a source tarball for libffi?
msg366525 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-15 15:20
In master, we build against the latest build out of that repo, which comes from the libffi branch (not the 3.3.0 RC).

In 3.8 (and 3.7? I forget) we use the 3.3.0 RC build. There's no later release from libffi (last I checked), and no important fixes since then (only ARM64 support, which we contributed).

We'll probably tag for 3.9.0b1 and retarget the master branch to take that one, so that we can control updates that go into that release. But right now there isn't anything we want to tag right now (and GitHub generates the tarball itself, so we don't have to upload anything - you can get the branch tip through the "Download" button on the front page).
msg366526 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-15 15:23
To save the clicks, here's the URL that will get the latest sources from the libffi branch:
msg366528 - (view) Author: Gregory Szorc (indygreg) * Date: 2020-04-15 16:16
I don't like utilizing the dynamic archive links like (even if you pin the commit) because GitHub does not guarantee the file content is deterministic over time. I perform SHA-256 validation of all dependencies I download from the Internet. And if I rely on the /archive/ URLs, all it takes is GitHub updating some library that subtly changes the tar/zip structure and my hashes are invalidated.

Release artifacts are immutable and don't have this problem.

As it stands, I will likely `git clone` and check out the commit I need. Although I would prefer a release artifact.
msg366534 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-15 18:13
When we make a beta release, you can have a release artifact. Until then, if you're building against the master branch, you can use the dependency's "master" branch.

I've renamed the issue so it can serve as a reminder to tag whatever version we use for beta 1.
Date User Action Args
2020-04-15 18:13:00steve.dowersettitle: cpython-source-deps project missing release for libffi commits -> Tag libffi build and sources in cpython-source-deps for 3.9.0b1
messages: + msg366534
versions: + Python 3.9
2020-04-15 16:16:59indygregsetmessages: + msg366528
2020-04-15 15:23:10steve.dowersetmessages: + msg366526
2020-04-15 15:20:43steve.dowersetmessages: + msg366525
2020-04-15 15:02:42indygregcreate