Building C core fail on Mac OS when it is from other package

[pontakornth]

Describe the bug
There is some build error I have no idea to fix. The log is really long so I used https://pastebin.com/M9HPypc0.

The problem does not occur if I install python-igraph with pip install python-igraph but it only occurs when a package tried to build python-igraph wheel. That's why I am not sure if Python part interfere with this part or not.

To reproduce

1. Use pip install cso-classifier (pip install python-igraph does not have problem)
2. Wait until it tried to build python-igraph.

Version information
0.10.4 that seem to be installed along cso-classifier

Mac OS 13.2.1

[ntamas]

cso-classifier pinned down the version number of python-igraph at 0.9.x (can't remember which exactly). This is an old and currently unsupported version (as you can see, the new macOS compilers throw an error with some of the constructs that were used in python-igraph 0.9.x but they are not used any more in 0.10.4). You should ask the maintainer of cso-classifier to bump python-igraph to 0.10.4, or, even better, replace python-igraph in the dependencies with igraph completely as python-igraph is now only a compatibility alias to igraph (and we should have stopped supporting it in Sept 2022).

[szhorvat]

@ntamas I'm not sure why, but it seems that pip install will sometimes build igraph from sources instead of using binaries. Do you have any idea what may trigger this? See e.g. scikit-mobility/scikit-mobility#264

In view of this, would it make sense to set IGRAPH_WARNINGS_AS_ERRORS=OFF when building python-igraph? I'm on the fence about this since we want to learn about new compiler warnings ASAP. But unlike with C/igraph, python-igraph users might find it difficult to resolve such issues on their own.

[ntamas]

I'm not sure why, but it seems that pip install will sometimes build igraph from sources instead of using binaries.

It will build from source if none of the published wheels on PyPI are compatible with the current Python installation. See this page for more details. We have IGRAPH_CMAKE_EXTRA_ARGS as an envvar that allows the user to inject extra args to the CMake invocation so this can be used to prevent warnings from being treated as errors.

I'm leaning towards setting IGRAPH_WARNINGS_AS_ERRORS to OFF in future versions, though. We test the C core enough on our own with all sorts of compilers in CI envs so we are likely to notice issues there on our own - there is no need to repeat the same checks when testing the Python interface. I find it unlikely that there's a compiler that is routinely used to compile the Python interface of igraph but we don't test it in the C core on its own.

Opinions?

[szhorvat]

I'm leaning towards setting IGRAPH_WARNINGS_AS_ERRORS to OFF in future versions

👍 , agreed that this is the way to go.