Update to the latest c-code template

[mgedmin]

Add a regression test for CFLAGS not having -Ofast, which is known to break things. See zopefoundation/meta#155 for reference.

[icemac]

Hm, according to coveralls the new test does not run: https://coveralls.io/builds/52359729/source?filename=src%2Fzodbpickle%2Ftests%2Ftest_compile_flags.py
@mgedmin Do you have an idea why this could happen?

[mgedmin]

Hm, according to coveralls the new test does not run.
@mgedmin Do you have an idea why this could happen?

Good catch! That would be because tox.ini does

commands =
    # there's test_pickle_2 for Python 2 and test_pickle_3 for Python 3
    # different test files because metaclass syntax differs on Pythons
    # test_pickle picks and returns the appropriate one
    # without this we'd get an import error (actually syntax error) for one
    # of them
    zope-testrunner --test-path=src -m zodbpickle.tests.test_pickle$ {posargs:-vc}

and, for tox -e coverage,

    coverage run -m zope.testrunner --test-path=src -m zodbpickle.tests.test_pickle$ {posargs:-vc}

(And similar things in buildout.cfg and GitHub Actions, most of them by way of custom test commands in .meta.toml)

I'll see what I can do (probably rename test_pickle_{2,3}.py so their file names don't start with test, after all they're included in the test suite explicitly inside test_pickle.py).

[mgedmin]

Wiped some caches:

$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-3.10
$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-3.11.0-rc.1

Retried the two failing jobs with debug logging. Found cp310 and cp311 wheels in the Linux-pip-pypy-3.7 cache.

../../../.cache/pip/wheels/26/eb/0c/413ef3f3b51eac5046ef623fab8d71f429297aefda870af4f8/zope.interface-5.4.0-cp311-cp311-linux_x86_64.whl
../../../.cache/pip/wheels/21/a9/8b/0bfc5594d8e109d5b25d6b69e0cff14d09d93e3522dcb16d2b/zope.interface-5.4.0-cp310-cp310-linux_x86_64.whl

Wiped it

$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-pypy-3.7

Retried again.

[mgedmin]

Linux-pip-2.7 cache also has things like

../../../.cache/pip/wheels/26/eb/0c/413ef3f3b51eac5046ef623fab8d71f429297aefda870af4f8/zope.interface-5.4.0-cp311-cp311-linux_x86_64.whl
../../../.cache/pip/wheels/21/a9/8b/0bfc5594d8e109d5b25d6b69e0cff14d09d93e3522dcb16d2b/zope.interface-5.4.0-cp310-cp310-linux_x86_64.whl

$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-2.7

At this point I think every single cache is poisoned with bad cp310 and cp311 wheels, so

$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-3.5
$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-3.6
$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-3.7
$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-3.8
$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-3.9
$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-pypy-2.7

I would love to know how that sort of thing happens.

[mgedmin]

Another cache existed: Linux-pip-3.11.0-beta.3.

$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches?key=Linux-pip-3.11.0-beta.3

Are there more?

$ gh api -H "Accept: application/vnd.github+json" /repos/zopefoundation/zodbpickle/actions/caches|jq -r .actions_caches[].key|sort

None of them start with "Linux-pip-"

[mgedmin]

I would love to know how that sort of thing happens.

Theory: when you add a new Python version to the build matrix, there's no Linux-pip-3.10 cache, so it uses a compatible Linux-pip-2.7 or something, builds a bunch of new wheels, and then instead of creating Linux-pip-3.10, updates Linux-pip-2.7.

Nah, can't be right, that would mean the new cache for Linux-pip-3.10 wouldn't ever get created.

Could it be that the cache action both updates the old compatible cache and creates the new one? Would be strange to me...

[icemac]

LGTM.

Thank you for making the test setup way easier!