build: Detect if Python.h header is present

[igaw]

Make sure the devel package is also installed not just the the Python
interpreter.

Signed-off-by: Daniel Wagner dwagner@suse.de

Fixes: #72

[igaw]

@eli-schwartz sorry to ask such a simple question but I was not able to find anything in the meson documentation on this topic.

Is this the way how we are supposed to check if 'Python.h' is installed on the system? One thing which bothers me, do we actually know it's the matching Python.h version with the Python interpreter found in the path.

[eli-schwartz]

The py3_dep should ensure that the include directory from the matching interpreter is found first, if at all. BTW you could use cc.has_header for this.

You should never find the wrong header either, because it won't ever be directly in the default search path as /usr/include/Python.h, it will always have a versioned subdirectory defined with -I.

Usually the fact that a dependency is successfully found means that the development headers must be installed, but python is a bit special as we can resolve it via sysconfig if pkg-config files are absent. I wonder if that could be fixed in meson...

[igaw]

Thanks @eli-schwartz. Will change to cc.has_header.

The question on which Python interpreter is used popped up in #72. If I understood it correctly, during the setup step Python 3.6 (with devel package installed) is detected. But during the build Python 3.9 is used which doesn't have the Python.h header file installed. Hmm, that would also mean my header test here wouldn't be enough I suppose.

[igaw]

On a second thought, if in #72 Python 3.6 is found (so my previous claim is wrong about two different python version invovled) but there is nothing checking if the header files are present this PR would indeed be the right fix.

[eli-schwartz]

during the setup step Python 3.6 (with devel package installed) is detected. But during the build Python 3.9 is used

I don't understand this. If you have multiple versions of python installed on your system (one of which has a devel package installed, and which you want to build against) then meson will always consistently use whichever python it found in find_installation. It may be the wrong python, hence no devel headers, but it should NEVER detect one during meson setup and then write out ninja rules which use the other.

If the wrong python is detected, this can be overridden using, for example, a --native-file foo.ini with a binaries table specifying the path to the python interpreter (which is then used by find_program('python3') as well as find_installation('python3')).

Which one is the "right" python in meson's original detection may be based on which one the python3 symlink points at, or the one meson itself is running under... Meson does some guesswork here and it can be OS and system dependent. (Meson will generally fall back on the python it runs under, if it cannot find it elsewhere).

[igaw]

during the setup step Python 3.6 (with devel package installed) is detected. But during the build Python 3.9 is used

I don't understand this. If you have multiple versions of python installed on your system (one of which has a devel package installed, and which you want to build against) then meson will always consistently use whichever python it found in find_installation. It may be the wrong python, hence no devel headers, but it should NEVER detect one during meson setup and then write out ninja rules which use the other.

Sorry, my bad. I got confused again because I was still thinking in the Makefile based world :)
So all should be good.

If the wrong python is detected, this can be overridden using, for example, a --native-file foo.ini with a binaries table specifying the path to the python interpreter (which is then used by find_program('python3') as well as find_installation('python3')).

Nice! Thanks for explaining.

[eli-schwartz]

No problem, happy to help. :)

sorry to ask such a simple question

It's not necessarily such a simple question. ;)

Anyway, I'm actually quite willing to have people ping me for meson questions and/or ask for my style review on meson changes (no promises about project specific details, but I can definitely provide advice on what meson is capable of).