testen, ob Python.h vorhanden

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Donnerstag 7. Februar 2008, 09:42

Hoi,

ich bin gerade dabei das Setup eines Paketes von mir so zu verbessern, daß es wirklich einjeder installieren kann.
U. a. prüft jetzt setup.py, ob alle Abhängigkeiten erfüllt sind und gibt ggf. Info darüber wie best. Abhängigkeiten gelöst werden können. Bei Pythonmodulen: Kein Problem. Aber wie teste ich darauf ob die Python dev.-Files vorhanden sind? Den meisten Leuten sagen entsprechende Nachrichten vom Compiler nichts, also: Wie teste ich, ob "#include <Python.h>" funktionieren wird, so daß das Setupskript entsprechend warnen kann? (OS-unabhängig natürlich ;-).

Gruß,
Christian
noise
User
Beiträge: 62
Registriert: Donnerstag 7. Februar 2008, 00:15

Donnerstag 7. Februar 2008, 15:02

Hi, machst du das mit distutils?
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Donnerstag 7. Februar 2008, 15:27

Ja. Ich überlege gerade, ob es nicht besser ist einfach draufloszukompilieren und Fehler abzufangen. Ist zwar ein wenig aufwändig, wenn es sauber sein soll, aber machbar. Oder gibt es in distutils eine builtin-Lösung? (Habe nichts gefunden.)

Gruß,
Christian
Gnushi
User
Beiträge: 77
Registriert: Dienstag 12. Dezember 2006, 09:49

Donnerstag 7. Februar 2008, 15:55

Hi!
CM hat geschrieben: wie teste ich darauf ob die Python dev.-Files vorhanden sind?
Kleiner Vorschlag:

Das geht auf unixähnlichen Systemen mit dem Gespann aus 'automake' und 'autoconf'. Letztlich wird ein Shellskript namens 'configure.sh' erzeugt, welches dann den Code zum Prüfen enthält.

Alternative:
Du könntest schauen, welche Version von Python installiert ist. Anschließend findest Du heraus, ob /usr/include/pythonPYTHONVERSION/Python.h oder
/usr/local/include/pythonPYTHONVERSION/Python.h vorhanden ist.

GnuShi
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Donnerstag 7. Februar 2008, 16:03

automake und autoconf oder configure-Skripte vertragen sich aber irgendwie schlecht mit einer Lösung mittels distutils.

Die Alternative wäre natürlich rel. unproblematisch - aber wie mache ich das auf Windows? Gibt es da ebenfalls spez. Pfade? (Ahnungslosigkeit meinerseits - habe noch nie mit diesem OS *richtig* gearbeitet.)

Gruß,
Christian
noise
User
Beiträge: 62
Registriert: Donnerstag 7. Februar 2008, 00:15

Donnerstag 7. Februar 2008, 16:28

CM hat geschrieben:Ja. Ich überlege gerade, ob es nicht besser ist einfach draufloszukompilieren und Fehler abzufangen. Ist zwar ein wenig aufwändig, wenn es sauber sein soll, aber machbar. Oder gibt es in distutils eine builtin-Lösung? (Habe nichts gefunden.)

Gruß,
Christian
Ah OK, dann ist alles klar :)
CM hat geschrieben: Die Alternative wäre natürlich rel. unproblematisch - aber wie mache ich das auf Windows? Gibt es da ebenfalls spez. Pfade? (Ahnungslosigkeit meinerseits - habe noch nie mit diesem OS *richtig* gearbeitet.)

Gruß,
Christian
Garnicht, den das macht alles für dich distutils :)
Und zwar: Python wird auf Windows per Binary-Setup installiert und dabei trägt sich einiges an Infos in die Registry ein. Der Pfad zu python, etc. Und in jeder Installation wird auch das include und libs mit installiert. Sprich es sind alle Informationen und Files vorhanden um eine Python-Extension zu bauen.

Das einzige was du zusätzlich mache kannst ist in der README einzutragen das Windows user die kein Visual C++ habe mingw installieren und, ``python setup.py build -c mingw32`` + ``python setup.py install`` eintragen um mit mingw das ganze zu backen. Damit habe ich gute Erfahrung und konnte bisher alle extensions auf Windows backen. OT: Es heißt ja das man eigentlich die extensions mit Visual C++ backen muss, aber mein erfahrung und die der anderen lehren uns das eigentlich fast alles sich mit einem aktuellen mingw auch backen lässt.

Kurz: Wenn Python regulär auf Windows installiert wurde und der User (besser Entwickler) den Python Pfad in die Umgebungsvariable eingetragen hat, genügt für ihm ein ``python setup.py`` bzw. ``python setup.py build -c mingw32`` + ``python setup.py install``. Den Rest erledigt distutils.

Optional kannst du wenn du willst für Window user **mit** distutils eine setup.exe backen, in der alle extensions Vorkompiliert sind. Der nachteil ist, das du für jede von dir unterstützte Python Version so eine exe backen musst, da ja immer gegen die jeweilige Python lib gelinkt werden muss (Siehe wxPython). Das ist für dich als Entwickler Mehraufwand aber für den Entwickler der deine Lib nutzt viel praktischer :)

HTH
noise

P.S.: Ich hoffe ich hab nicht all zuviel geschrieben.

EDIT: PPS: Auf Python.h brauchst du mit distutils nicht zu testen, den wenn einer so dumm ist bei seinem installierten Pyhon das include Verzeichnis zu löschen, hat er es nicht anders verdient ;)
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Donnerstag 7. Februar 2008, 16:37

noise hat geschrieben:EDIT: PPS: Auf Python.h brauchst du mit distutils nicht zu testen, den wenn einer so dumm ist bei seinem installierten Pyhon das include Verzeichnis zu löschen, hat er es nicht anders verdient ;)
Unter Linux stecken Header-Dateien etc. meist in extra Devel-Paketen und werden standardmaessig nicht mitinstalliert.

CM, du koenntest ein kleines Testprogramm compilieren:

Code: Alles auswählen

#include <Python.h>
int main(){}
Und dann schauen, ob ein Fehler auftritt und in der Ausgabe "Python.h" auftaucht...
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
noise
User
Beiträge: 62
Registriert: Donnerstag 7. Februar 2008, 00:15

Donnerstag 7. Februar 2008, 16:54

Rebecca hat geschrieben:
noise hat geschrieben:EDIT: PPS: Auf Python.h brauchst du mit distutils nicht zu testen, den wenn einer so dumm ist bei seinem installierten Pyhon das include Verzeichnis zu löschen, hat er es nicht anders verdient ;)
Unter Linux stecken Header-Dateien etc. meist in extra Devel-Paketen und werden standardmaessig nicht mitinstalliert.
Hallo Rebecca,

das trifft auch auf distutils zu ;) In python-dev (auf debian basierende), python-devel, ...Sprich, wenn auf nem debian like system kein Devel installiert ist, kann man es ehe nicht mit distutils installieren, da es schlicht und einfach fehlt.

Davon abgesehen:
CM hat geschrieben: aber wie mache ich das auf Windows? Gibt es da ebenfalls spez. Pfade? (Ahnungslosigkeit meinerseits - habe noch nie mit diesem OS *richtig* gearbeitet.)
Und darauf habe ich mich bezogen. Aber auch hier: Wer Python-Entwickler auf Linux ist und zu dumm ist sich **nicht** die devels installiert, hat es nicht anders verdient ;) Sorry, aber sehe ich leider so und ich hoffe es kommt nicht zu pampig rüber. Weil hin und wider installiert man ja auf Linux Libs die ebenfalls das backen einer Extension erfordern...
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Donnerstag 7. Februar 2008, 16:57

Hallo Christian!

Du kannst mit den distutils auch Installationsdateien für Windows erstellen. Diese sind dann ausführbare EXE-Dateien.

Unabhängig davon: Wenn du etwas einem Windows-User nicht zutrauen kannst, dann, dass sich dieser ein MINGW installiert um sich die DLLs über die distutils bauen zu können. Vergiss es! Das funktioniert nicht. Liefere lieber fertig gebaute DLLs für Windows mit. Einmal für Win32 und einmal für Win64 (wenn du auch schon auf Python64 vorbereitet sein willst).

Im Programm prüfst du die Plattform ab und lädst nach Bedarf die Win32- oder die Win64-DLL.

Das gilt jetzt aber nur, wenn du ein Python-Paket erstellen möchtest. Wenn du ein eigenständiges Programm schreiben möchtest, dann bist du mit den distutils mehr als schlecht bedient. Denn alles wird in den "site-packages"-Ordner installiert und es gibt keine Möglichkeit, den Installationsordner in einem Windows-Setup einstellbar zu machen. Das ginge zwar in Ansätzen, wenn man ``python setup.py install`` aufruft, aber das ist ja nicht der einfachste Weg für den Benutzer.

Ich habe vor einiger Zeit mal das Programm InstallJammer http://www.installjammer.com/ entdeckt. Damit soll man angeblich (ich habe es leider noch nicht ausprobiert) Programminstallationen für Windows und Linux erstellen können. Was ich bis jetzt sagen kann: Es scheint wirklich toll zu sein und wird laufend weiterentwickelt.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Donnerstag 7. Februar 2008, 17:22

gerold hat geschrieben:Unabhängig davon: Wenn du etwas einem Windows-User nicht zutrauen kannst, dann, dass sich dieser ein MINGW installiert um sich die DLLs über die distutils bauen zu können. Vergiss es! Das funktioniert nicht. Liefere lieber fertig gebaute DLLs für Windows mit. Einmal für Win32 und einmal für Win64 (wenn du auch schon auf Python64 vorbereitet sein willst).
Tja, aber das erfordert a) Zugang zu einem Windowsrechner mit Python und b) Muße mich damit auseinanderzusetzen.

Also, ich habe ein Paket geschrieben - ganz bewußt. Und ich richte mich an Wissenschaftler, keine Programmierer, aber mit ein paar Beispielskripten sollten sie eigentlich loslegen können. Also braucht ich wohl ggf. einen engagierten Nutzer, das auf Windows mal vorzubacken.

Die Idee auf mingw-hinzuweisen finde ich gut.

Überhaupt waren das bisher tolle Kommentare. Vielen Dank euch allen! Werde mir das mal durch den Kopf gehen lassen.

Gruß,
Christian
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Donnerstag 7. Februar 2008, 17:25

noise hat geschrieben: das trifft auch auf distutils zu ;) In python-dev (auf debian basierende), python-devel, ...Sprich, wenn auf nem debian like system kein Devel installiert ist, kann man es ehe nicht mit distutils installieren, da es schlicht und einfach fehlt.
Mmh:

Code: Alles auswählen

> apt-file search distutils
python2.4: usr/lib/python2.4/distutils/README
python2.4: usr/lib/python2.4/distutils/__init__.py
python2.4: usr/lib/python2.4/distutils/archive_util.py
python2.4: usr/lib/python2.4/distutils/bcppcompiler.py
python2.4: usr/lib/python2.4/distutils/ccompiler.py
python2.4: usr/lib/python2.4/distutils/cmd.py
python2.4: usr/lib/python2.4/distutils/command/__init__.py
python2.4: usr/lib/python2.4/distutils/command/bdist.py
python2.4: usr/lib/python2.4/distutils/command/bdist_dumb.py
...

Code: Alles auswählen

> apt-file search Python.h
python2.4-dev: usr/include/python2.4/Python.h
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
noise
User
Beiträge: 62
Registriert: Donnerstag 7. Februar 2008, 00:15

Donnerstag 7. Februar 2008, 17:26

gerold hat geschrieben:Hallo Christian!

Du kannst mit den distutils auch Installationsdateien für Windows erstellen. Diese sind dann ausführbare EXE-Dateien.
Das schrieb ich bereits:
noise hat geschrieben: Optional kannst du wenn du willst für Window user **mit** distutils eine setup.exe backen, in der alle extensions Vorkompiliert sind. Der nachteil ist, das du für jede von dir unterstützte Python Version so eine exe backen musst, da ja immer gegen die jeweilige Python lib gelinkt werden muss (Siehe wxPython). Das ist für dich als Entwickler Mehraufwand aber für den Entwickler der deine Lib nutzt viel praktischer :)
Aber zu folgenden Punkte ein par Anmerkungen, wenn sie gestattet sind:
gerold hat geschrieben: Unabhängig davon: Wenn du etwas einem Windows-User nicht zutrauen kannst, dann, dass sich dieser ein MINGW installiert um sich die DLLs über die distutils bauen zu können. Vergiss es!
Sorry, aber mit verlaub, das ist Schwachsinn! Wenn er eine Library schreibt (Und das habe ich verstanden, korrigiere mich wenn es anders ist) die Python-Entwickler benutzten können, dann kann man es schon von einem Entwickler erwarten das er es hinkriegt ein par Bunte Knöpfe zu drücken um mingw zu installieren! Oder ist hier zufällig einer der mit Python auf nem Windows-System arbeitet der das nicht hinkriegt!?

Gerold, verstehe mich bitte nicht falsch, aber wir reden hier von Programmierern und nicht von durchschnittlichen Benutzern die gerade mal wissen wie ein E-Mail Programm und office funktionieren.
gerold hat geschrieben: Das funktioniert nicht. Liefere lieber fertig gebaute DLLs für Windows mit. Einmal für Win32 und einmal für Win64 (wenn du auch schon auf Python64 vorbereitet sein willst).

**snipp**
Im Programm prüfst du die Plattform ab und lädst nach Bedarf die Win32- oder die Win64-DLL.

Das gilt jetzt aber nur, wenn du ein Python-Paket erstellen möchtest.
Ja, aber er muss, und das habe ich auch erwähnt, das er auch für alle von Ihm unterstützten Python-Versionen eine extra setup.exe backen muss. Konkret: Wenn er Python 2.3, 2.4, 2.5 unterstützen möchte muss er für alle diese dreien eine setup.exe backen. Denn es muss immer gegen die jeweilige `libpython*.a` gelinkt werden, sonst funktioniert es nicht. Das ist, wie ich schon schrieb, ein Mehraufwand. Natürlich ist es aus unserer Sicht die später seine Libarary benutzten bequemer, aber was spricht gegen ein ``python setup.py build -c mingw32`` + ``python setup.py install``? Soviel mehraufwand ist es doch auch nun wider nicht. Und wenn er es in der README bzw. INTALL schreibt wie man das auf Windows hinkriegt, das sollte man schon von einem Programmierer (und nicht nur von dem) erwarten das er mal ein Par Minuten seiner Zeit zum lesen opfert.

gerold hat geschrieben: Wenn du ein eigenständiges Programm schreiben möchtest, dann bist du mit den distutils mehr als schlecht bedient.
Ja wenn es nur durchschnittliche Benutzer sind, sind solche oft damit überfordert.
gerold hat geschrieben: Denn alles wird in den "site-packages"-Ordner installiert und es gibt keine Möglichkeit, den Installationsordner in einem Windows-Setup einstellbar zu machen. Das ginge zwar in Ansätzen, wenn man ``python setup.py install`` aufruft, aber das ist ja nicht der einfachste Weg für den Benutzer.
Mit Windows-Setup meinst du ein Binary-Setup gebacken von distutils? Wenn nicht dann, auch auf Windows kann man einstellen das es wo anders als auf in den site-packages Ordner Installiert wird (Natürlich nicht wenn es ein Binary-Setup gebacken von distutils ist). Es langt schlicht und einfach ein ``--prefix="c:\my programm"``.
gerold hat geschrieben: Ich habe vor einiger Zeit mal das Programm InstallJammer http://www.installjammer.com/ entdeckt. Damit soll man angeblich (ich habe es leider noch nicht ausprobiert) Programminstallationen für Windows und Linux erstellen können. Was ich bis jetzt sagen kann: Es scheint wirklich toll zu sein und wird laufend weiterentwickelt.
Sorry aber ich finde ein Binary-Setup für Linux mehr als schlecht. Gerade das ist doch das schöne an Python, das ich kleine Programme installieren kann die in ausführbaren source code vorliegen. Also warum sotte ein ernsthafter Linux-Benutzer eine gefreezte variante gegenüber eine in source code Form bevorzugen, bzw. eine Binary Setup gegenüber eines setups von distutils?

Sind die Leute heute echt mit einem ``python setup.py install`` überfordert? :shock: Auch verstehe ich nicht wie es kommt das alle denken das Windows User alle voll DAUs sind :roll:

my 0.1€

noise
noise
User
Beiträge: 62
Registriert: Donnerstag 7. Februar 2008, 00:15

Donnerstag 7. Februar 2008, 17:36

Rebecca hat geschrieben: Mmh:
Rebecca, es ist allgemein bekannt das distutils nicht auf allen (Sprich auf einigen schon aber noch lange nciht auf jeden) Linuxen standardmäßige dabei ist sondern über die devels zu beziehen ist.

Bein installieren der devels wird dann distutils **selbstverständlich** dort installiert wo man es dann z.B. über PYTHONPATH beziehen kann (in deinem Fall `usr/lib/python2.4/distutils`).

Davon abgesehen ist auf meinen debian-like system distutils NUR über die entsprechenden devels zu beziehen und nicht im Standard package dabei. Beweisen kann ich es selbstverständlich nicht, aber du kannst ruhig mal andere debian und debian-like user fragen.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Donnerstag 7. Februar 2008, 17:41

noise hat geschrieben:Sorry aber ich finde ein Binary-Setup für Linux mehr als schlecht. Gerade das ist doch das schöne an Python, das ich kleine Programme installieren kann die in ausführbaren source code vorliegen. Also warum sotte ein ernsthafter Linux-Benutzer eine gefreezte variante gegenüber eine in source code Form bevorzugen, bzw. eine Binary Setup gegenüber eines setups von distutils?
Da kann ich mich nur anschliessen.
noise hat geschrieben:Auch verstehe ich nicht wie es kommt das alle denken das Windows User alle voll DAUs sind :roll:
Weil es oft so ist ;) Abgesehen davon fehlen Windows User die Tools um "mal schnell" Software zu installieren. Ein weiterer Punkt is Gewohnheit. Windows User wollen ihre installer. Linux User wollen entweder Packete oder den Source.
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
noise
User
Beiträge: 62
Registriert: Donnerstag 7. Februar 2008, 00:15

Donnerstag 7. Februar 2008, 17:57

veers hat geschrieben: Weil es oft so ist ;) Abgesehen davon fehlen Windows User die Tools um "mal schnell" Software zu installieren. Ein weiterer Punkt is Gewohnheit. Windows User wollen ihre installer. Linux User wollen entweder Packete oder den Source.
Naja, OK, das stimmt schon. Aber dennoch denke ich das es schlicht ein Klischee ist das alle Windows User DUAs sind (OK, das hast du zwar nicht gesagt, aber das ist ja so die allgemeine Haltung im Web). Natürlich kenne ich einige Windows DAUs aber bestimmt auch genauso viele Linux DAUs die ohne DE nicht klar kommen.


Christian, ich würde mich bereit erklären deine Lib mal auf Windows zu backen und zu schauen ob es Funktioniert oder ob du an einigen Stellen unportablen C-Code geschrieben hast.
Antworten