Embedding Python with C++

[merman]

"Ken Seehof" <kseehof at neuralintegrator.com> schrieb im Newsbeitrag
news:mailman.1018363820.30451.python-list at python.org...
> >
> > > merman wrote:
> > > > Hi Ken,
> > > >
> > > > can I use your wizard with bcc55 too?
> > > >
> > > > o-o
> > > >
> > > > Thomas
> >
> > Ken wrote:
> > > No, it's a plug-in for the Visual C++ IDE.
> > >
> > > However you should be able to compile the generated code
> > > created by PyExtWizard with bcc.
> > >
> > > Much of the code generation functionality is independent
> > > of Visual C++, so it would be a feasible project to make
> > > PyExtWizard a multi-platform tool.  I will eventually
> > > need to do this for my own needs.  The GUI for the tool
> > > will be in wxPython.
> > >
> > > - Ken
>
> merman wrote:
> > ... thanx Ken - but I have VS7.NET (Beta2).
> > There are too much failures if I compile - no chance.
>
> Haven't tried it, but I doubt that VS7.NET supports VC6 wizards.
> Both products are by Microsoft and are therefore incompatible :-)
> If the old wizards don't work, it's useless to try to compile
> PyExtWizard (see below).
>
> > and with swig:
> > Maybe is my Makefile not valid - yesterday I posted it to
comp.lang.python
> > (thread swig-problem from merman).
> > I have try it with swig and bcc55 under win2k.
>
> You won't get anywhere :-(  SWIG has nothing to do with anything here.
>
> > Last error-messages from bcc55 are:
> >
> > Error: Unresolved external '_Py_InitModule4' referenced from
> > C:\MYC\PY_EXT\TREE_
> > WRAP.OBJ
> > Error: Unresolved external '_PyModule_GetDict' referenced from
> > C:\MYC\PY_EXT\TRE
> > E_WRAP.OBJ
> >
> > ... and so on. Is there a linker-probem?
> > I have no solution.
> >
> > o-o
> >
> > regards
> >
> > Thomas
>
> I think you misunderstood me.  You won't be able to build
> PyExtWizard with anything other than MS Visual C++ (MSVC++ 6.0).
> It makes no sense to build it with anything else since it is a
> plug-in wizard for MSVC++.  PyExtWizard is not a stand-alone
> application.  As a plug-in, it enhances VC++ by allowing you to
> create a new VC++ projects that implement python extension modules.
>
> It makes no sense to use SWIG on PyExtWizard.  PyExtWizard is not
> an API and it does not contain any C++ code that anyone would have
> any reason to wrap.  The code generation functionality is implemented
> in python and uses the capabilities of the MSVC++ wizard system.
>
> When I said, "you should be able to compile the generated code
> created by PyExtWizard with bcc", I meant that if you were to use
> PyExtWizard with Visual C++ to generate a new python extension
> module to your specifications, you would probably be able to compile
> the resulting code with a different compiler (hopefully anywhere).
>
> In other words, PyExtWizard is not portable at all, but it should
> generate portable code (this hasn't been tested yet).  I guess you
> could call it a "cross wizard" (Harry Potter on a bad hair day :-)
>
> I alluded to my future intent to make PyExtWizard independent of
> Visual C++, and therefore portable.  This would involve the following
> steps:
>
> 1. Throw away -all- of the C++ code.  The C++ portion of PyExtWizard
> serves only to interact with the MSVC++ IDE.
>
> 2. Replace the MSVC++ wizard functionality with python code.
>
> 3. Reimplement the GUI in wxPython.
>
> - Ken Seehof

Hi,

I think I understand you Ken - I only choose two ways to solve my problem:

first way:
with swig/ bcc55/ Makefile (see copmiler-messages above)

second way:
I used your PyExtWizard + VS7.NET without success - you know that.
I have no VC6.

I thought you have experience with SWIG maybe.

Last year I used swig/ gcc/ Makefile under Suse-Linux for the same purpose
and it runs!
But not so under win2k today. And I don't know why, you know?

Thats the problem.

best regards

thomas