Tests fail to find Python.h

[yurivict]

First it failed like this:

In file included from /usr/local/include/pybind11/pytypes.h:12:
/usr/local/include/pybind11/detail/common.h:186:10: fatal error: 'Python.h' file not found
#include <Python.h>
         ^~~~~~~~~~

then it failed like this:

In file included from /usr/local/include/xtensor-python/pytensor.hpp:22:
/usr/local/include/xtensor-python/pycontainer.hpp:30:10: fatal error: 'numpy/arrayobject.h' file not found
#include "numpy/arrayobject.h"
         ^~~~~~~~~~~~~~~~~~~~~

I had to add these arguments to fix these failures:

CXXFLAGS=-I${PYTHON_INCLUDEDIR} -I${PYTHON_SITELIBDIR}/numpy/core/include

It should find relevant headers by itself.

[SylvainCorlay]

When things are not found, the right definition to add is PYTHON_EXECUTABLE. We have found that more aggressive search strategies often ended up finding other python installs and linking with the wrong version.

[yurivict]

cmake finds the python executable fine:

-- Found PythonInterp: /usr/local/bin/python3.8 (found version "3.8.12") 
-- Found PythonLibs: /usr/local/lib/libpython3.8.so

It can't find the headers. Based on docs the same command that finds the python executable, FindPython, outputs the headers' location.

[SylvainCorlay]

Thanks. Is this happening on a distribution a patched cpython distribution? We rely on the same approach as pybind11 for this ...

[yurivict]

This is happening in the FreeBSD port.

[SylvainCorlay]

Okay. I don't know if the freebsd port patches cpython. We had some serious headaches in the past with Debian patching it to split between dist-packages and site-packages. In any case we should address the freebsd case.

[tdegeus]

Not sure if this is the issue : https://conda-forge.org/docs/maintainer/knowledge_base.html ?