Python 3.13 compatibility

[dehnert]

Trying to build with Python 3.13 (and commit 300a924, aka https://github.com/macathena/python-afs/tree/py3 -- which is dubiously appropriate for this repo, but Macathena doesn't have issues enabled) gives:

* Getting build dependencies for wheel...
* Building wheel...
[1/1] Cythonizing afs/_util.pyx
/nix/store/wsrjvz1x8y73zcnsvf9wa3rl9vvj2532-python3.13-cython-3.0.12/lib/python3.13/site-packages/Cython/Compiler/Main.py:381: FutureWarning: Cython directive 'language_level' not set, using '3str' for now (Py3)>
  tree = Parsing.p_module(s, pxd, full_module_name)
In file included from /nix/store/0m7q35xsmz8arjy18jfsshfqvf5ga7j8-openafs-1.8.13.2-dev/include/afs/prclient.h:11,
                 from afs/_util.c:1267:
/nix/store/0m7q35xsmz8arjy18jfsshfqvf5ga7j8-openafs-1.8.13.2-dev/include/ubik.h:171:17: error: field ‘cache_lock’ has incomplete type
  171 |     struct Lock cache_lock; /*!< protects cached application data */
      |                 ^~~~~~~~~~
error: command '/nix/store/rw8447qyjljmfiac0hhfc2jrspjnpn75-gcc-wrapper-14.2.1.20250322/bin/gcc' failed with exit code 1

ERROR Backend subprocess exited when trying to invoke build_wheel

It looks like Py3.13 ships with include/python3.13/lock.h, which conflicts with OpenAFS's lock.h.

I'm not actually sure what one usually does about this -- patch one of OpenAFS and Python as part of the build process?

[dehnert]

I guess the good news is this isn't a problem in any currently release LTS -- 25.04 introduced python3.13.

[geofft]

I wonder if you can convince Cython to put the OpenAFS headers first in the search path.

If it weren't Cython, you could try to build separate .o files, one using Python's CFLAGS and one using OpenAFS's.

But honestly I feel like this is a bug in both Python and OpenAFS. <lock.h> is too generic of a name. Python's is slightly better in that it's under the python3.13 subdirectory; OpenAFS seems to install a /usr/include/lock.h!

[geofft]

I opened a CPython issue since these days I'm more familiar with that project, the breaking change was in CPython, and it seems like the header could be renamed without much trouble since it's recent and doesn't seem to be part of the documented API. It might also be worth trying to open an issue in OpenAFS, but given that the header name dates to at least OpenAFS 1.0 and presumably much longer in IBM/Transarc/CMU AFS, there might be backwards compatibility issues there.

[kaduk]

The OpenAFS lock.h seems to be an API from the legacy LWP threading model (though it is restricted to use with LWP-threaded code), which is largely deprecated in favor of the opr_lock.h routines. So there would be some path to changing things in upstream OpenAFS, I think, though it would probably not be particularly fast.