Hallo,
ich habe gerade etwas von Modulen gelesen. Dabei wurde erwähnt, dass ich diese zwar selbst erstellen, aber nur in einen best. Ordner ablegen kann.

Mir wäre es lieber, wenn ich solche Module im selben Verzeichnis, wie das Perl-Script liegen habe (ähnlich #include bei C/C++). Geht das auch?

Oder muss ich für sowas was anderes (keine Module) benutzen?

Danke,
pixelflat

Natürlich geht das auch... Wo hast Du das her, dass man die in einen bestimmten Ordner speichern muss?

Du musst perl nur sagen, welche Verzeichnisse es zusätzlich nach Modulen durchsuchen soll. Das geht mit use lib.

Hilfreich ist in Verbindung mit use lib auch gerne mal FindBin:

renee+2007-09-18 13:00:19--

Natürlich geht das auch... Wo hast Du das her, dass man die in einen bestimmten Ordner speichern muss?

das ist so ein mythos, der aus irgendeinem grund noch in umlauf ist. daher glauben
auch viele, dass sie keine "externen module" benutzen können. ich frag mich,
ob das so in irgendeinem buch steht...

Oh, danke!

pq+2007-09-18 13:41:48--

renee+2007-09-18 13:00:19--

Natürlich geht das auch... Wo hast Du das her, dass man die in einen bestimmten Ordner speichern muss?

das ist so ein mythos, der aus irgendeinem grund noch in umlauf ist. daher glauben
auch viele, dass sie keine "externen module" benutzen können. ich frag mich,
ob das so in irgendeinem buch steht...

In dem Buch steht wahrscheinlich auch, dass man Perl nicht kompilieren kann.

Das geht? Oo

Sprich, ich könnte dann das Script/Programm ohne Interpreter ausführen?

Klares Jein. Du kannst dein Script nicht so compilieren, dass der Prozessor es nativ, also ohne Interpreter ausführen kann. Du kannst es aber auf jeden Fall so compilieren, dass der Interpreter es nicht mehr selber Compilieren muss. Das daraus resultierende Ergebnis nennt man Bytecode. Das kann in einigen Spezialfällen Geschwindigkeitsvorteile bringen.
Außerdem kann man mit PAR eine Art Paket aus Interpreter, Script und den benötigten Modulen schnüren, welches dann selbstständig lauffähig ist. Dies bringt aber keine Vorteile in Punkto Geschwindigkeit oder Speicherbedarf des Programms, sondern ist lediglich dazu gedacht, Anwendungen für den Endbenutzer komfortabel aufzubereiten. Allerdings ist PAR in der Praxis nicht einfach zu bedienen.

Taulmarill+2007-09-19 15:18:52--

Klares Jein. Du kannst dein Script nicht so compilieren, dass der Prozessor es nativ, also ohne Interpreter ausführen kann. Du kannst es aber auf jeden Fall so compilieren, dass der Interpreter es nicht mehr selber Compilieren muss. Das daraus resultierende Ergebnis nennt man Bytecode. Das kann in einigen Spezialfällen Geschwindigkeitsvorteile bringen.

Hmm, auch ein "jaein".
Mit "perlcc" kannst du auch native ELF Binaries erstellen, und dann benötigst du ebenfalls keinen perl Interpreter mehr.

Allerdiengs auch nen "jaein", weil der Interpreter letztendlich auch nur im Binary eingebaut wird, und der Interpreter letztendlich immer noch gestartet wird. Schneller wird es also nicht. Möglicherweise kann es sogar langsamer werden.

Ansonsten wird das ganze sowieso nicht Offiziel Supported, weswegen es Meiner Meinung nach vernachlässigbar ist.

--------------------

Und zu der Aussage zu "pktm". Jedes Perl Skript wird vor seiner Ausführung "kompiliert"... Und ich denke er wollte eher darauf hinaus.

Der Begriff "kompilieren" bezeichnet nicht native Binaries zu erstellen, sondern eine Sprache von einer zu einer anderen Sprache zu übersetzen. Jeder Perl Sourcecode wird vor seiner verwendung "kompiliert". Nämlich wird Perl Sourcecode in einem bytecode umgewandelt. Und dieser wird letztendlich von einem Interpreter ausgeführt. Und Interpreter die Bytecode ausführen nennt man neuerdings "Virtuel Maschine". Genau soetwas ist Perl. Nur halt mit Compiler und Virtuel Maschine in einem, anstatt getrennt (so wie bei Java).