Christian Heimes wrote: > On 09/12/2021 19.26, Petr Viktorin wrote: > > If the code is the authoritative source of truth, we need a proper > > parser to extract the information. ... unfortunately I don't trust it > > enough to let it define the API. Bugs in the parser could result in > > the API definition silently changing.
> There are other options than writing a new parser. GCC and Clang are > flexible. For example GCC can be extended with plugins and custom > attributes. But they have the same problem ... it can be difficult to know if there is a subtle bug in someone's understanding of how the plugin interacts with, for example, nested ifndef. The failure mode for an explicitly manually maintained text file is that something doesn't get added when it should, and the more conservative API consumers wait an extra release before using it. -jJ We could extend the header files with custom attributes and > then use a plugin to create an ABI file from the attributes. > I created a quick n' hack > https://github.com/python/cpython/compare/main...tiran:gcc-pythonapi-plugin?... > > as proof of concept. > The plugin takes > PyAPI_ABI_FUNC(PyObject *) PyLong_FromLong(long); > and dumps the declaration as: > extern struct PyObject * PyLong_FromLong (long int); "abi_func" > Christian _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PKQFEIK75EWVTNMLB5CGBYLQANZG6QJH/ Code of Conduct: http://python.org/psf/codeofconduct/
