Error with GCC 15

[lahwaacz]

Building mwparserfromhell with GCC 15 results in this error:

gcc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/python-mwparserfromhell-git/src=/usr/src/debug/python-mwparserfromhell-git -flto=auto -fPIC -Ilib -I/usr/include/python3.13 -c src/mwparserfromhell/parser/ctokenizer/avl_tree.c -o build/temp.linux-x86_64-cpython-313/src/mwparserfromhell/parser/ctokenizer/avl_tree.o
src/mwparserfromhell/parser/ctokenizer/avl_tree.c:24:13: error: ‘bool’ cannot be defined via ‘typedef’
   24 | typedef int bool;
      |             ^~~~
src/mwparserfromhell/parser/ctokenizer/avl_tree.c:24:13: note: ‘bool’ is a keyword with ‘-std=c23’ onwards
src/mwparserfromhell/parser/ctokenizer/avl_tree.c:24:1: warning: useless type name in empty declaration
   24 | typedef int bool;
      | ^~~~~~~
warning: build_ext: building extension "mwparserfromhell.parser._tokenizer" failed: command '/usr/bin/gcc' failed with exit code 1

To make things worse, the Python build (python -m build --wheel) continues regardless and results in a wheel without the C tokenizer.

[earwig]

We'll definitely need to fix that.

To make things worse, the Python build (python -m build --wheel) continues regardless and results in a wheel without the C tokenizer.

But at least I think this is desirable; the wheels we publish to PyPI assert that the C tokenizer built successfully. If someone is building it from source and they're in an untested configuration where building the C tokenizer may not work, probably they'd rather have a slow Python tokenizer than nothing...

[lahwaacz]

If someone is building it from source and they're in an untested configuration where building the C tokenizer may not work, probably they'd rather have a slow Python tokenizer than nothing...

IMHO it would be better to have some flag for switching between the 3 desirable outcomes: build the C tokenizer and stop if it fails, build the C tokenizer if possible but continue if it fails, and don't build the C tokenizer at all.

[earwig]

Yeah, you're probably right. Guess that means my attempt at doing everything in pyproject.toml is nonviable, for now at least.

[earwig]

OK, main now supports export WITH_EXTENSION=0|1|optional while building to make this explicit. There's a behavior change from the previous release that the default behavior is now required instead of optional but we have a clearer error message that should make the fallback easy to opt-in to.

[earwig]

This is fixed in 0.7.1.

[lahwaacz]

Thanks!