embed python

[Marc Schellens]

Can somebody tell me how to handle
this #include issue when embedding python?
Why NOT (according to the python doc) ude
#include <python2.3/Python.h>
?

And which is the library to link if I want to
use pyhton from my application?

Is there a standard way to deal with that issue?

thanks,
marc

[Peter Strempel]

In article <c2***********@news.riken.go.jp>, Marc Schellens wrote:

Can somebody tell me how to handle
this #include issue when embedding python?
Usually "#include "Python.h" is the right way. Then tell your compiler
to add "python2.3" to the include list. On gcc pass "-I/usr/include/python2.3"
or similar to the compilation step.
Why NOT (according to the python doc) ude
#include <python2.3/Python.h>
?
Well, you actually can do that, it will work just as above way. But when
you upgrade your Python to 2.4, you need to change your sourcecode. Otherwise
you only need to change your Makefile.

Maybe there is another, more important reason. I don't know. :)

And which is the library to link if I want to
use pyhton from my application?

-lpython2.3 (or -lpython23 on some systems) will find the right library,
which is libpython2.3.so in most cases (or libpython23.so or python23.dll
if you are on Win32).
Peter

[Marc Schellens]

Thanks Peter,

In article <c2***********@news.riken.go.jp>, Marc Schellens wrote:

Can somebody tell me how to handle
this #include issue when embedding python?

Usually "#include "Python.h" is the right way. Then tell your compiler
to add "python2.3" to the include list. On gcc pass "-I/usr/include/python2.3"
or similar to the compilation step.

Why NOT (according to the python doc) ude
#include <python2.3/Python.h>
?

Well, you actually can do that, it will work just as above way. But when
you upgrade your Python to 2.4, you need to change your sourcecode. Otherwise
you only need to change your Makefile.

ok, but why everybody writes #include "Python.h" instead of
#include <Python.h> ? The latter form is the corrcet one for
header files wich are not part of the actual project.

marc

[Peter Strempel]

In article <c3***********@news.riken.go.jp>, Marc Schellens wrote:

Usually "#include "Python.h" is the right way.

ok, but why everybody writes #include "Python.h" instead of
#include <Python.h> ? The latter form is the corrcet one for
header files wich are not part of the actual project.

Yes, you are right. Should be <Python.h>. I was sloppy in my post.
GCC should be generous and accept "Python.h", too, but it might not
work with all compilers.

I checked my current project code, it has <Python.h>. I don't know what
everyone else writes. :)

Not exactly related to your question, but if you are doing embedding,
have a look at Pyrex which can be misused for extremely simple embedding
as it saves you the need to write all the C boilerplate code. This isn't
exactly what Pyrex is made for, but is a wonderful way to save some
time and efforts.

Peter

[Erik Max Francis]

Marc Schellens wrote:

ok, but why everybody writes #include "Python.h" instead of
#include <Python.h> ? The latter form is the corrcet one for
header files wich are not part of the actual project.

It's a minor point. The <...> notation is for system headers, the "..."
notation is for non-system headers, but will fall back to searching
system headers as well.

If it works at all -- and you haven't chosen deliberately conflicting
filenames -- then it doesn't matter which one you use.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Sometimes we're blinded by the light / If we'd only use our eyes
-- Oleta Adams