Hal Murray <hmur...@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> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel