Python.h is broken on NetBSD and FreeBSD

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> How does that work?
> 
> On Linux, it's in:
>   /usr/include/python2.7/Python.h
> but the code does:
>   #include <Python.h>
> 
> On NetBSD, it's in:
>   /usr/pkg/include/python2.7/Python.h
> 
> On FreeBSD, it's in:
>   /usr/local/include/python2.7/Python.h

What the build system is expected to do is add the local path to Python.h
to the list of inclusions it passes to the compilation of your project's
Python extension or extensions.

(For the uniniatiated: A Python extension is a shared library that makes
the C functions in it available as though they were part of a loadable
Python module. I needed to build a Python extension to make certain functions
from libntp visible to the Python translation of ntpq - in particular the
code for handling l_fp timestamps.  Trying to duplicate that in pure Python
would have been insane.)

Matt Selsky and I are looking into that right now. We think waf has the
capability to autoconfigure this, but the documentation is rather opaque.
It's going to take some digging.

(The extension will also help when we replace the C ntpdig and write
the so-far-hypothetical ntpshark.)

Boosted by this, the translation is going very well. I now have about
3/4ths of the command set implemented, including the all-important
"peers" command. Various unusual cases still need polishing and testing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>