On May 5, 2005, at 5:28 PM, Frederick C. Lee wrote:
> I'm following an c-module example in 'Programming Python'.
>
> The C code depends on 'Python.h'.
>
> The first thing I did was use Spotlight to find where 'Python.h' is.
> I found it: /Developer/SDKs/MacOSX10.4.0.sdk/..../include/
> python2.3/Python.h <-- def as PYHEADERS env variable in .login.
>
> So I set the 'Header Search Paths' under 'Search Paths' in XCode
> via $PYHEADERS env variable that I had set in my .login file.
> But this has no effect within XCode Build.
It looks like you're trying to develop an extension module. You want
to use distutils to build these, not Xcode. If you use Xcode, you
will do it wrong.
#include <Python.h> is *NEVER* correct, it should always be #include
"Python.h", with the appropriate include directory added to the
search path.
The options required for linking to Python are always available from
distutils:
>>> import disuttils
>>> import pprint
>>> pprint.pprint(distutils.sysconfig.get_config_vars())
{.... a very very large dict full of crap from the makefile...}
However, using Xcode to build+link extensions is NOT the right way to
do it, even if you can deduce the right flags to use by looking at
these config vars.
If you are *embedding* Python on Mac OS X you probably should
consider just writing a PyObjC based plugin that encapsulates what
you need Python to do, and then just call into that from your
Objective-C application. If you try and embed Python manually you'll
probably get it wrong, and PyObjC saves you from having to deal with
any of the Python C API.
-bob
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
