Python Interpreter für C++ nutzen

[Krux]

Ok ich hab mal das bespielprogramm so kompiliert, wie es da Steht, und kopiert, das resultat, c.a. 25 000 Fehler bei 12 Zeilen Quellcode.

#include <boost/python.hpp>
using namespace boost::python;

char const* greet()
{
   return "hello, world";
}

BOOST_PYTHON_MODULE(hello)
{
    def("greet", greet);
}

unter anderem hab ich folgende Fehler:

In file included from /usr/local/include/boost/python/detail/prefix.hpp:13,
                 from /usr/local/include/boost/python/args.hpp:8,
                 from /usr/local/include/boost/python.hpp:11,
                 from helloWorld.cc:1:
/usr/local/include/boost/python/detail/wrap_python.hpp:50:23: error: pyconfig.h: No such file or directory
/usr/local/include/boost/python/detail/wrap_python.hpp:75:24: error: patchlevel.h: No such file or directory
/usr/local/include/boost/python/detail/wrap_python.hpp:78:2: error: #error Python 2.2 or higher is required for this version of Boost.Python.
/usr/local/include/boost/python/detail/wrap_python.hpp:142:21: error: Python.h: No such file or directory

Ich hab sowol Python2.4 als auch Python2.5 inklusive den dev Paketen installiert, aber scheinbar gibt es keine default Version oder so, jedenfalls findet er die header nicht. Sie sind aber alle vorhanden.

Ich glaub kaum, dass es jetzt die richtige Lösung wäre, wenn ich die gesamten Fehlermeldungen durchforste, und die entsprechenden Phython header in einen der dafault Include Ordner packe, zumal die da ja eigentlich schon drin sind, nur in ihren Unterordnern. Was hab ich vergessen zu konfigurieren?

Ich hab Ubuntu 7.04

[.filmor]

Also bei mir schaut das so aus, dass ich "/usr/include/python-<version>" zum Includepfad dazu gesetzt habe. Dann geht das auch ohne dieses myllige Boost.Build. Der nächste Fehler, der wahrscheinlich kommt ist, dass irgendwas Py*-mäßiges fehlt. Dann linkst du noch die libpython<version> dazu.

Nun willst du wahrscheinlich den Kram in deine Anwendung einbetten. Dafür ist das Tutorial in der Boost-Doku /sehr/ dürftig. Wenn du das obige alles geschafft hast (also der Kram /ohne/ Boost.Build kompiliert und läuft), dann meld dich nochmal, dann kann ich dir ein Beispiel geben.

[hustbaer]

Wenns einfach sein soll nimm LUA, das ist VIEL einfacher einzubinden als Python und muss vor allem nicht installiert werden (wird einfach zu deinem Programm dazugelinkt).

[Krux]

hustbaer schrieb:

Wenns einfach sein soll nimm LUA, das ist VIEL einfacher einzubinden als Python und muss vor allem nicht installiert werden (wird einfach zu deinem Programm dazugelinkt).

LUA scheint recht interessant zu sein, aber nicht ganz dem zu entsprechen, was ich für mein Projekt haben möchte, LUA hat bytecode, und ich würde gerne über eine Konsole ein Programm steuern können. Da ich allerdings nicht selber so eine Konsole erstellen möchte, hab ich mir gedacht, wäre eine konsole, die mir zusätzlich auch noch die möglichketen von Python gibt sehr vorteilhaft. Geschwindigkeit ist mir erstmal nicht wichtig.

.filmor schrieb:

Also bei mir schaut das so aus, dass ich "/usr/include/python-<version>" zum Includepfad dazu gesetzt habe. Dann geht das auch ohne dieses myllige Boost.Build. Der nächste Fehler, der wahrscheinlich kommt ist, dass irgendwas Py*-mäßiges fehlt. Dann linkst du noch die libpython<version> dazu.

Nun willst du wahrscheinlich den Kram in deine Anwendung einbetten. Dafür ist das Tutorial in der Boost-Doku /sehr/ dürftig. Wenn du das obige alles geschafft hast (also der Kram /ohne/ Boost.Build kompiliert und läuft), dann meld dich nochmal, dann kann ich dir ein Beispiel geben.

naja, am System herumfummeln, nur damit es einer Anwedung passt, das nenne ich Fortschlitt, aber das boosteigene build-System, möchte ich nicht noch lernen, da ich eine IDE und nicht blos ein Editor benutze, würde das viele Vorteile der IDE gleich wieder zu nichte machen. für die dynamische Version von python, hätte auch eine Variable im Quellcode gereicht, die man in der main irgendwo festlegen kann. Aber ich bin ja nicht der Erfinder von Boost, ich weiß nur grad nicht, wie man Systemvariablen ändert.

[rüdiger]

Hast du Boost per Hand installiert? Wenn ja: Warum? Nimm doch die fertigen Pakete. Die sollten dir dann auch die benötigten Python Header als Abhängigkeit installieren...

[Krux]

rüdiger schrieb:

Hast du Boost per Hand installiert? Wenn ja: Warum? Nimm doch die fertigen Pakete. Die sollten dir dann auch die benötigten Python Header als Abhängigkeit installieren...

ich hab boost selbst compiliert, und mit dem Install-Skript installiert, weil die fertigen Pakete nicht auf der neusten Version waren. Aber die pythonheader sind doch da, nur nicht da, wo sie gesucht werden.

Edit, ich hab jetzt noch mal etwas geändert:

#include <python2.5/pyconfig.h>
#include <python2.5/patchlevel.h>
#include <python2.5/Python.h>
#include <boost/python.hpp>
using namespace boost::python;

char const* greet()
{
   return "hello, world";
}

BOOST_PYTHON_MODULE(hello)
{
    def("greet", greet);
}

jetzt gibt es schonmal weniger kompilierfehler:

g++    -c -g -o build/Debug/GNU-Linux-x86/helloWorld.o helloWorld.cc
In file included from /usr/local/include/boost/python/detail/prefix.hpp:13,
                 from /usr/local/include/boost/python/args.hpp:8,
                 from /usr/local/include/boost/python.hpp:11,
                 from helloWorld.cc:4:
/usr/local/include/boost/python/detail/wrap_python.hpp:50:23: error: pyconfig.h: No such file or directory
/usr/local/include/boost/python/detail/wrap_python.hpp:75:24: error: patchlevel.h: No such file or directory
/usr/local/include/boost/python/detail/wrap_python.hpp:142:21: error: Python.h: No such file or directory
make[1]: *** [build/Debug/GNU-Linux-x86/helloWorld.o] Fehler 1
make[1]: Verlasse Verzeichnis '/home/arne/Arbeitsbereich/Netbeans/pythontest'
make: *** [.build-impl] Fehler 2

Build failed. Exit value 2.

Wenn es jetzt noch ein Makro gäbe, mit dem include fehler ignoriert werden, oder einfach nur bestimmer include anweisungen, dann würde ja alles funktionieren, denn bis auf die include Anweisungen funktioniert ja alles

Edit2:

mir ist da grad so eine spontane Idee gekommen:
wenn nach folgender Methode includiere:

#define PV <python2.5
#include PV/Python.h>

dann zeigt mir zwar meine IDE fehler an, aber der Kompiler arbeitet völlig ohne Fehler . Ich könnte mir doch die boost libraries so umändern, dass ich bevor ich sie einbinde so dynamisch im Quellcode immer die Version von Python bestimmen kann.

Ach ja der Fehler der IDE:

Cannot find include file <Python2.5 /Python.h>

aber wie gesagt, ich kann fehlerfrei kompilieren (Die IDE baut da ein Leerzeichen ein, wo es der Kompiler nicht tut). Aber eigentlich möchte ich nicht an den BOOST libraries herumwerkeln

[LordJaxom]

Wie wäre es mit Hinzufügen des Pfades zum Suchpfad des Compilers, statt irgendwo in den Headern rumzuwursten?

[rüdiger]

Krux schrieb:

rüdiger schrieb:

Hast du Boost per Hand installiert? Wenn ja: Warum? Nimm doch die fertigen Pakete. Die sollten dir dann auch die benötigten Python Header als Abhängigkeit installieren...

ich hab boost selbst compiliert, und mit dem Install-Skript installiert, weil die fertigen Pakete nicht auf der neusten Version waren. Aber die pythonheader sind doch da, nur nicht da, wo sie gesucht werden.

Die Boost-Sachen via apt-get zu installieren erspart dir viel Ärger. Aber wenn du nicht willst

Du kannst dem Compiler Suchpfade für Header angeben. Schau dir mal die -I-Option an. Bei IDEs kann man das idr direkt in den Projekt-Einstellungen angeben (C bzw C++ Flags)

[.filmor]

hustbaer schrieb:

Wenns einfach sein soll nimm LUA, das ist VIEL einfacher einzubinden als Python und muss vor allem nicht installiert werden (wird einfach zu deinem Programm dazugelinkt).

Python wird auch nur dazugelinkt...

Krux schrieb:

LUA scheint recht interessant zu sein, aber nicht ganz dem zu entsprechen, was ich für mein Projekt haben möchte, LUA hat bytecode, und ich würde gerne über eine Konsole ein Programm steuern können. Da ich allerdings nicht selber so eine Konsole erstellen möchte, hab ich mir gedacht, wäre eine konsole, die mir zusätzlich auch noch die möglichketen von Python gibt sehr vorteilhaft. Geschwindigkeit ist mir erstmal nicht wichtig.

Python ist ausreichend schnell. Ich mache zz sogar die Graphik meines Programms zu großen Teilen in Python (vorrangig zum Prototyping). Btw, um die Konsole toller zu machen, solltest du auf jeden Fall ipython verwenden.

Krux schrieb:

naja, am System herumfummeln, nur damit es einer Anwedung passt, das nenne ich Fortschlitt, aber das boosteigene build-System, möchte ich nicht noch lernen, da ich eine IDE und nicht blos ein Editor benutze, würde das viele Vorteile der IDE gleich wieder zu nichte machen.

Da hast du mich völlig missverstanden. Ich meinte genau das, was rüdiger zuletzt vorgeschlagen hat. Und ich meinte auch, du solltest gerade /nicht/ Boost.Build für dein eigenes Programm verwenden. Boost baut man natürlich nur damit, oder besser mit dem zur Distribution gehörenden Paketmanager!

[hustbaer]

.filmor schrieb:

hustbaer schrieb:

Wenns einfach sein soll nimm LUA, das ist VIEL einfacher einzubinden als Python und muss vor allem nicht installiert werden (wird einfach zu deinem Programm dazugelinkt).

Python wird auch nur dazugelinkt...

Oha, sorry, ich wusste nicht dass das geht.
Naja, ok, es geht wie ich gerade selbst festgestellt habe.

Krux schrieb:

LUA scheint recht interessant zu sein, aber nicht ganz dem zu entsprechen, was ich für mein Projekt haben möchte, LUA hat bytecode, und ich würde gerne über eine Konsole ein Programm steuern können. Da ich allerdings nicht selber so eine Konsole erstellen möchte, hab ich mir gedacht, wäre eine konsole, die mir zusätzlich auch noch die möglichketen von Python gibt sehr vorteilhaft. Geschwindigkeit ist mir erstmal nicht wichtig.

Was du mit "LUA hat bytecode" meinst weiss ich nicht. LUA lässt sich mit Bytecode oder Text füttern, ganz nach belieben. Python generiert auch erstmal Bytecode und führt den dann aus. Ist in beiden Fällen aber transparent, sollte also egal sein. Ob man Python mit Bytecode direkt füttern kann weiss ich nicht, ist aber für dich eh nicht wichtig wenn ich dich richtig verstanden habe.

----

Ich will dir Python aber natürlich nicht ausreden, dachte mir nur ich erwähne LUA mal weil ich LUA eben viel einfacher finde. Wenn LUA noch Integers hätte wäre ich fast schon glücklich damit

[Krux]

hustbaer schrieb:

Was du mit "LUA hat bytecode" meinst weiss ich nicht. LUA lässt sich mit Bytecode oder Text füttern, ganz nach belieben. Python generiert auch erstmal Bytecode und führt den dann aus. Ist in beiden Fällen aber transparent, sollte also egal sein. Ob man Python mit Bytecode direkt füttern kann weiss ich nicht, ist aber für dich eh nicht wichtig wenn ich dich richtig verstanden habe.

Ja so weit ich weiß, kann man ja zu Bytecode compilieren, dann müsste man es ja auch damit füttern können, aber wie gesagt, ich würde Python gerne als Konsole verwenden, da ist es für mich erst mal zweitrangig, ob sowas mglich ist. LUA hab ich wirklich nur ganz kurz überflogen, weil ich davon bisher noch absolut nichts gehört hatte.

Ich will dir Python aber natürlich nicht ausreden, dachte mir nur ich erwähne LUA mal weil ich LUA eben viel einfacher finde. Wenn LUA noch Integers hätte wäre ich fast schon glücklich damit

Wie soll man ohne integers Indizes ansprechen? Naja wird wohl irgendwie möglich sein.

[Artchi]

Lua kann sowohl Sourcecode als auch Bytecode vearbeiten. Aber am Ende muß man das selber wissen was man nimmt, da beide Sprachen unterschiedlich sind und auch die Performance beachtliche Unterschiede aufweist.

[.filmor]

Öhm, es geht wohl um die Konsole, da wirds wohl absolut und völlig unwichtig sein, ob man die mit Bytecode füttern kann

Btw, hier ein Minimalbeispiel:

#include <boost/python.hpp>

namespace bp = boost::python;

const char* initial_program = 
    "import __main__, IPython\n"
    "IPython.Shell.IPShell(user_ns = __main__.__dict__).mainloop()\n";

int main (int argc, char** argv)
{
    try
    {
        Py_Initialize ();
        PySys_SetArgv (argc, argv); // setzt sys.argv

        bp::object global = bp::import ("__main__").attr ("__dict__");

        {
            bp::scope s (global);
            // hier Funktionen aufrufen, die class_, def etc. ausführen (*)
        }

        bp::exec (initial_program, global, global);
    }
    catch (boost::python::error_already_set const&)
    {
        PyErr_Print ();
    }
    Py_Finalize ();
}

Du kannst das eigentliche Programm, das hier in initial_program als C-String vorliegt natürlich auch mit den Boost.Python-Mitteln implementieren, aber der Aufwand ist imho nicht gerechtfertigt.

zu (*): Du kannst hier, wenn du BOOST_PYTHON_MODULE verwendet hast die entsprechende init_module_<Modulname>-Funktion aufrufen, die das Makro automatisch anlegt.

[hustbaer]

Krux schrieb:

Ich will dir Python aber natürlich nicht ausreden, dachte mir nur ich erwähne LUA mal weil ich LUA eben viel einfacher finde. Wenn LUA noch Integers hätte wäre ich fast schon glücklich damit

Wie soll man ohne integers Indizes ansprechen? Naja wird wohl irgendwie möglich sein.

Naja, double ist ja "integer clean" sozusagen. Also wenn du 1.0 reinsteckst, dann + 1.0 rechnest und dann == 2.0 prüfst, dann geht das schon. Da LUA sowieso nur assoziative "Tables" kennt geht das auch mit double. Ist aber IMHO greislich hässlich.

[Krux]

ok hab nach einer kleinen pause mich jetzt noch mal dazu aufgerafft, hier weiter zu machen. Also kompilieren kann ich jetzt, aber von dem tutorial her ist mir noch schleierhaft, wie ich das ganze eigentlich überhaupt unter linux kompilieren soll, denn im Tutorial steht nur etwas von einer DLL, und die gibts unter linux nicht. Ich habs als Dynamic Library Kompiliert. Wenn ich jetzt allerdings versuche das ganze in python zu testen, kkommt folgender Fehler:

import libpythontest
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: ./libpythontest.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE

[rüdiger]

btw. http://www.boostcon.com/var/sphene/sphwiki/attachment/2007/06/01/Extreme_Object_Models_Using_Boost.Python.pdf

[.filmor]

Natürlich gibt es unter Linux DLLs. Die haben zwar ELF und nicht PE als Dateiformat und enden auf .so, aber dennoch existieren sie. Leg vielleicht mal die erstellte libboost_python.so in das Arbeitsverzeichnis.

[rüdiger]

.filmor schrieb:

Leg vielleicht mal die erstellte libboost_python.so in das Arbeitsverzeichnis.

NEEEEEIN!!! So was macht man über die Umgebungsvariable LD_CONFIG_PATH