Variablen aus Perlprogramm in C einlesen

[piet]

Hallo,

ich habe eine perllib mit Namen /usr/lib/perl5/.../database_data.pm in der verschiedene Parameter, Unterprogramme zum steuern vieler anderer perlprogramme stehen.

Hier steht unter anderem

our $stringlaenge = 8196;

Nun möchte ich diese variable ($stringlaenge) auch in einem C Programm benutzen (nur lesen) Wie integriere ich diese database_data.pm in mein C-Programm um auch eventuell später mehrerer andere Variablen auszulesen. Ich möchte natürlich diese Datei nicht mit "open" usw. öffnen, sondern als "lib" in C integrieren, .... wenn möglich. Wenn ich es neu machen würde, würde ich einfach eine "configdatei-Textdatei" erstellen, jetzt ist es aber zu aufwändig alle anderen Perl-Programme zu ändern.

Danke
  piet

[pl]

Also eine Konfiguration die sowohl in Perl als auch in C verfügbar ist. Das führt Dich zu einer Datei die

1. sowohl mit Perl als auch mit C zu lesen und
2. von einer jeden Programmiersprache unabhängig ist.

Beispiel siehe oben. Darüber hinaus gibt es Serializealgorithmen.

MFG

PS: Damit Deine Perlprogramme davon unberührt bleiben, erarbeite ein Deploy-Prozess in Perl welcher die Perlkonfiguration in ein für C lesbarees Dateiformat exportiert.

[Patrick C.]

Hallo piet,

es gibt wohl die Möglichkeit, Perl in C einzubetten (siehe POD perlembed), allerdings habe ich damit keinerlei Erfahrung und ich weiß nicht, ob es nicht mit Kanonen auf Spatzen geschossen wäre.

Das einfachste wäre wahrscheinlich wirklich, die Variable „von Hand“ auszulesen oder wie bereits vorgeschlagen, in eine Config-Datei auszulagern. Du hattest aber bereits erwähnt, dass es wohl zu aufwendig wäre. Vielleicht ist ja ein Kompromiss möglich, dass nur Teile der Konfiguration ausgelagert werden.

Gruß
Patrick

[pl]

Vielleicht ist ja ein Kompromiss möglich, dass nur Teile der Konfiguration ausgelagert werden.

Das Zauberwort heißt Deployment. MFG

[Rolf B]

Hallo Patrick,

Das einfachste wäre wahrscheinlich wirklich, die Variable „von Hand“ auszulesen

Ich kann mir mehrere Möglichkeiten vorstellen.

1. Das C-Programm fasst diese database_data.pm Datei als Config-Datei mit eigenwilligem Format auf und sucht sich die Zeilen heraus, die es benötigt. Das setzt voraus, dass die .pm Datei einem erträglich lesbaren Schema folgt und die Config-Werte Konstanten sind. Sind es Ausdrücke, ist es vorbei.

2. Man schreibt ein neues .pl Script, das die database_data.pm importiert und die für C benötigten Werte in ein C-freundliches Format exportiert. An der Stelle kommt PLs Stichwort "Deployment" zum Zuge - dieses Exportscript laufen zu lassen ist etwas, das Teil des Deployments ist und bei Installation einer neuen Programmversion auf dem Zielsystem automatisch ausgeführt werden muss, um konsistente Konfigurationsdaten zu haben. Man könnte natürlich auch im C-Teil an geeigneter Stelle die Timestamps von database_data.pm und database_data.dat vergleichen und bei Bedarf das Exportscript anstoßen, das setzt aber Schreibrecht der Anwendung auf ihre Runtime-Dateien voraus und sowas unterlässt man besser, um den Hackern das Leben nicht zu leicht zu machen. Eine Lösung ohne Extradatei wäre auch, wenn das Exportscript sein Ergebnis einfach aus stdout schreibt. Das C-Programm ruft es auf, klemmt sich vor das stdout des Exportprozesses und liest die Ausgabe des Exporters darüber ein. Ob das sinnvoll ist, hängt auch davon ab, wie oft man das tun muss.

3. Wenn die Config-Werte nicht zur Laufzeit gelesen werden müssen, sondern dem C-Programm "eingebrannt" werden können, kann man auch ein .pl Script schreiben, das aus der database_data.pm eine database_data.c oder database_data.h Datei generiert. Die nimmt man beim Compile der C-Module einfach mit hinzu.

Rolf

[pl]

Noch ne Idee: Die Konfig für C als eine .so (Shared Objects) Datei erzeugen mit Perl. Unter Windows also eine .dll

Für einen ordentlichen Deploymentprozess sollte es genügen das Makefile entsprechend anzupassen, at least

perl Makefile.PL
make
make test
make install

und das ganze Framework läuft. Perl liefert auch das Werkzeug dazu: h2xs

MFG

[Patrick C.]

Hallo Rolf,

schöne Ausführungen, soweit habe ich gar nicht gedacht. Ich persönlich finde deinen Punkt 2 am besten. Und da würde ich wirklich entscheiden, wie oft sich die Daten ändern.

Gruß
Patrick