Hallo,

in Rahmen eines größeren Projektes werden auch eigene Perlmodule erstellt.
Diese Module möchte ich gemäß den CPAN-Richtlinien erstellt haben. Deswegen halte ich mich gerne an die Anleitung von Renee (Wiki: Perlmodule erstellen).

Leider ist es aber so, daß die durch h2xs erstellte Verzeichnisstruktur nicht so gut passt innerhalb eines größeren Projektes.
Dort bräuchte ich eher eine Gliederung wie
./module/
Blafasel.pm
Blafasel/Helper.pm


wenn ich in ./module jedoch mit h2xs arbeite, krieg ich natürlich die Struktur wie sie in CPAN richtig ist und auf eigenständige Module basiert:
./module/Blafasel/
./module/Blafasel/lib/Blafasel.pm
./module/Blafasel/Makefile.PL
./module/Blafasel/README
./module/Blafasel/t
usw.

Natürlich könnte ich die Module ausserhalb des Projektes pflegen. Aber in der Praxis und wenn da mehrere Leute mitarbeiten, wird daraus nichts: Die Leute wollen schon in den jeweiligen Projektverzeichnissen direkt arbeiten. Schon weil die Versionsverwaltung und lokale Testversionen darauf zugreifen.

Wie also arbeitet man da am Besten?
Im Moment seh ich nur die Lösung, die h2xs-Struktur zu vergessen; Bzw. damit anzulegen und dann die Verzeichnisse umzuschieben und die Makefile anzupassen.

Wie macht ihr es?

Ciao,
Wolfgang

ich mach das immer so, dass ich einen Unterordner
lib anlege, und dort meine Module reintue (ohne h2xs). Wenn ich dann wirklich das ganze auf cpan stellen will, hab ich schonmal den lib ordner und muss dann nur noch das Makefile.pl schreiben einen Ordner höher legen und bin damit schon durch.

ansonsten ist die h2xs struktur eigentlich nur für entwicklung gedacht; danach kannst du Makefile.PL auf rufen und dann make install; damit installierst du deine Module auf dem system und bis genauso durch; nur hast du dann deine Module wirklich auf dem system installiert, und jedes perl script hat von überall dort zugriff (kann gut oder schlecht sein; je nachdem was man will und vorhat).

Naja, was die makefile mit "make dist" macht ist ja auch noch da.

Was ich aber eher als Problem sehe, sind die Versionen. Wenn ich aus einem Modul des Projektes auch ein CPAN-Modul mache, hab ich immer das Problem, daß ich immer drauf achten muss, daß die Versionsnummern des Moduls im Projekt nicht unbedingt gleich zu der im CPAN sein kann.

ich finde versionen ganz gut; ich hab mir angewöhnt, wenn ich an einem modul, dass eigentlich abgeschlossen war, die Version hochzudrehen, wenn ich wieder daran was ändere.

Ich auch :)

Nur ists halt nervig, wenn 2 oder mehr Projekte dieselben Module verwenden, diese aber nicht im System sondern im lokalen Projektordner liegen müssen.
Wenn dann ein Entwickler des Projektes A, das Modul ändert, kriegt der Entwickler des Projektes B dies natürlich nicht mit.

Ein eigenes "Modul-Projekt" wäre sicher als denkbare Lösung möglich, würde aber auch wieder das (schulische) Problem mit sich bringen, daß eben nicht alles was zu einem Projekt gehört in einem "Paket" (cvs checkout) ausgeliefert wird.

ein eigenes modul-repository klingt trotzdem sinnvoll. wer sagt denn, dass durch ein
cvs checkout alles notwendige geladen sein muss? nur bei auslieferung
als tar oder rpm solltest du alles in einer datei haben.\n\n

<!--EDIT|pq|1156839726-->

Hm...
ich werde es jetzt mal so versuchen daß ich im Projekt ein ./lib/-verzeichnis für die Module anlege.
Darin werden die Module dann gleich liegen.
Also:
./lib/Blafasel.pm
./lib/Blafasel/Helper.pm

Daneben werde ich die Test- und Makefiles in Unterverzeichnisse
./lib/t/
./lib/makefiles/
ablegen und die jeweilige Makefile.PL in
Modulname-Makefile.PL umbenennen.

Dann kann ich mir ein Shellskript machen, daß bei einen gewünschten CPAN-Export/Import die Dateien entsprechend rumschiebt und MANIEFEST und co erstellt, so daß ich eine saubere Dist krieg.

Denkbar oder Irrweg?

Wir arbeiten hier folgendermassen:

Unsere eigenen Module (=Klassen, wir programmieren ja objektorientiert oder nicht?) sind alle in einem Unterordner, IRGENDWO im Homeverzeichnis des Users. Darin wird editiert (mit xemacs und andere mit eclipse) getestet (!!! ) und von dort installieren wir das ganze in ein lib -Verzeichnis, von dem Apache (oder scripte die auch zur Applikation gehören) ihre Module laden.
Wichtig: dieses ganze Verzeichnis mit den Sourcen und den Testfiles verwalten wir per SVN.

Neue Module erzeugen wir mit module-starter als Make/Buildsystem nehmen wir Module::Build, das kann man so erweitern, dass der Pfad zur lib in welche installiert is, immer gleich richtig eingetragen ist (Doku zu Module::Build bzw. Module::Starter lesen).

Also ist der Ablauf:
- Plugin f. Module-Starter anlegen
- ~/.module-starter/config anlegen und plugin eintragen

Neues Modul anlegen z.bsp. im Verz. "trunk"
module-starter --mb --module=My::Module

dann in My-Module editieren und ./Build test, ./Build install usw.

Funktioniert soweit ganz brauchbar.

Der Nachteil , direkt im lib Verzeichnsi zu arbeiten ist m.E. schlicht, dass, wenn man zu mehreren Leuten arbeitet und einer etwas größeres ändert so dass die ganze Anwendung nicht funktioniert, andere auch nicht testen können!

Rolf