[Pythonmac-SIG] proper include for bundled h files

[Magladry, Stephen]

Thanks for the reply. I can access the <Python.h> file after adding the
access path to the header files. Case appears to be insignificant. 

I guess this leads to a bigger question on whether what I'm trying to
attempt is doable. Here's what we are trying to accomplish.

Currently we are developing a product. On the PC side, we use Python as our
executable and call out to platform specific stuff and potential Python
bottlenecks in c libraries. We have a system setup the generates the
interface files so that the Python code and C code stay in sync and are
callable back and forth.

With Apple's drive to Mach-O and the fact that a single package would help
to simplify distribution, I wanted to use the Python Bundle as our app and
store the C libraries in the appropriate folder within the bundle and load
them from there. Would this be advisable with the current state of the
Python bundled app? With the current state of Python Mach-O, should I just
fall back to Python CFM and cut my loses now?

Thanks for you feedback,

Stephen Magladry


-----Original Message-----
From: Jack Jansen [mailto:Jack.Jansen@oratrix.com]
Sent: Tuesday, June 11, 2002 1:19 PM
To: Magladry, Stephen
Cc: 'pythonmac-sig@python.org'
Subject: Re: [Pythonmac-SIG] proper include for bundled h files



On dinsdag, juni 11, 2002, at 08:38 , Magladry, Stephen wrote:

> I am having problems getting the h file recognized from my CW compiles,
> using a bundled Python. Here are the steps I have done.
>
> 1. Downloaded the  Python-2.2.1.tgz from python.org
> 2. Followed the directions in Mac/OSX folder to build bundled 
> version of
> Python in the default location /Library/Frameworks.
> 3. Use CodeWarrior stationary to build a C++ Toolbox Mach-O project.
> 4. Add the python.framework to the newly created project.
> 5. add a #include <python.h> line to the MyFramework.cp file.
> 6. Try to compile. Get a, "The file "python.h" cannot be 
> opened." error.

This will not work with the current state of the Python 
framework, for a number of reasons.

The main reason is that Python.framework is not a full-fledged 
framework. It is from the execution point of view (i.e. linking 
against it will do the right thing) but not from the compilation 
point of view.

If it was a full framework you should be able to do #include 
<Python/Python.h> (the capitalisation may be important), but (a) 
this hasn't been tested and (b) I strongly advise against this.

The reason for advising against this is that all Python 
extensions in the world do a simple #include "Python.h", and 
that the organization of the Python directory structure (plus 
distutils, etc etc etc) is setup to support this usage. If you 
were to distribute something with the <Python/Python.h> 
construct it would work only when building for OSX framework 
installations (and the unix crowds would start slagging us 
macheads for doing things incompatible, etc etc).

The solution is rather simple, though. You not only add the 
"-framework Python" option to your build, but also 
"-I/Library/Frameworks/Python.framework/Headers" (or, in 
CW-speak, add that directory to your search path), and do 
#include "Python.h" everywhere. Note that there's a precedent 
for this from Apple too: a similar trick is needed for OpenGL 
programs that use GLUT (or GLU, I forget).

All that said, I haven't tried using the CW Mach-O compiler to 
build MachoPython extensions (always used the unix tools for 
MachoPython), so you may run into other snags as well. Please 
report back here if you get it to work (or not:-).
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -