Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20095
Wohnort: Schwabenländle
|
Hallo, ich habe derzeit ein Programm, in dem GUI und die Funktionen dahinter fließend ineinander übergehen, was mich ziemlich stört. Ich wollte das jetzt trennen, nur wie macht man das korrekt? Ich habe zwei Fragen, wo ich nicht weiter weiß: 1) Nehmen wir an, der User will sich das Prog selbst kompilieren. Er hat dann einmal die Sourcen für die Library und die für die GUI. Die Lib kompilieren geht einfach, nur wohin damit? /usr/local/lib? Und wohin gehören die Header, so daß ich diese dann bei der GUI nutzen kann? Wie binde ich das dann korrekt bei der GUI-Kompilierung ein? 2) Ich werde wohl auch zwei Pakete draus machen. Eins mit der lib, eins mit der GUI. Muss man da auf was spezielles achten, oder kann man die Makefiles aus 1 als Basis nehmen? Gruß, Dee
|
haraldkl
Anmeldungsdatum: 21. Juli 2005
Beiträge: 1903
Wohnort: Würselen
|
Dee hat geschrieben: Hallo, ich habe derzeit ein Programm, in dem GUI und die Funktionen dahinter fließend ineinander übergehen, was mich ziemlich stört. Ich wollte das jetzt trennen, nur wie macht man das korrekt? Ich habe zwei Fragen, wo ich nicht weiter weiß: 1) Nehmen wir an, der User will sich das Prog selbst kompilieren. Er hat dann einmal die Sourcen für die Library und die für die GUI. Die Lib kompilieren geht einfach, nur wohin damit? /usr/local/lib? Und wohin gehören die Header, so daß ich diese dann bei der GUI nutzen kann? Wie binde ich das dann korrekt bei der GUI-Kompilierung ein?
/usr/local/lib ist das typische Verzeichnis dafür ja. Das wird auch automatisch durchsucht. Ansonsten könntest du sie auch irgendwo anders hinlegen, und /etc/ld.so.conf entsprechend anpassen. Oder du gibst den Pfad, in der die Library zu finden ist dem Linker an. Dee hat geschrieben: 2) Ich werde wohl auch zwei Pakete draus machen. Eins mit der lib, eins mit der GUI. Muss man da auf was spezielles achten, oder kann man die Makefiles aus 1 als Basis nehmen?
Kommt drauf an, ob du sie als shared library anlegen willst, oder nur eine Statische verwenden willst. Ich denke nicht, dass was gegen die Verwendung des Makefiles aus obigen Fall als Vorlage spricht. 😉
|
Lunar
Anmeldungsdatum: 17. März 2006
Beiträge: 5792
|
Ich denke, es ist ein bisschen früh, sich um die Pfade Gedanken zu machen. Aus eigener Erfahrung weiß ich, dass die Phrase "Die Logik von der GUI trennen" leicht gesagt ist, aber speziell bei schon einigermaßen ausgereiften (und natürlich nicht sauber getrennten) doch eher schwer umzusetzen ist. Deswegen würde ich das Ganze zwar schon in verschiedene Dateien, Namespaces, Klassen oder in was auch immer die gewählte Sprache noch für Möglichkeiten bietet, auftrennen, aber erstmal in einem Binary belassen. Das erleichtert die Arbeit und das Testen erstmal ungemein, da du dein Programm betreffend keine Linking-Fehler erhältst und auch nicht vergessen kannst, die neue Version der Library vor der neuen Programmversion zu übersetzen und zu installieren. Wenn alles läuft, kannst du dich immer noch um die Buildinfrastruktur kümmern. Nur ein paar Münzen von mir... Gruß lunar
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20095
Wohnort: Schwabenländle
|
/usr/local/lib ist das typische Verzeichnis dafür ja. Das wird auch automatisch durchsucht. Ansonsten könntest du sie auch irgendwo anders hinlegen, und /etc/ld.so.conf entsprechend anpassen. Oder du gibst den Pfad, in der die Library zu finden ist dem Linker an
Was wäre denn das einfachste? *g* Derzeit erstellt mein Makefile ja die Datei komplett und kopiert absolut gar nix irgendwohin, weil ich es selbst nicht mag, wenn das ein Prog macht.
Kommt drauf an, ob du sie als shared library anlegen willst, oder nur eine Statische verwenden willst.
Statisch sollte reichen. Hier im Forum erklärte man mir aber schonmal, daß es nur shared libraries gibt unter Linux. Insofern verwirrt mich deine Aussage... Gruß, Dee
|
haraldkl
Anmeldungsdatum: 21. Juli 2005
Beiträge: 1903
Wohnort: Würselen
|
Dee hat geschrieben: Was wäre denn das einfachste? *g* Derzeit erstellt mein Makefile ja die Datei komplett und kopiert absolut gar nix irgendwohin, weil ich es selbst nicht mag, wenn das ein Prog macht.
Das einfachste wäre du erstellst weiterhin alles in deinem lokalen pfad, nur eben eine library und ein Frontend Programm, das eben diese verlinkt. Beim linken sagst du ihm, dass er die library im aktuellen Pfad findet. Dann machst du noch ein install target, falls du es brauchst, mit dem die Library und das executable in die passenden Verzeichnisse kopiert werden. Dee hat geschrieben: Statisch sollte reichen. Hier im Forum erklärte man mir aber schonmal, daß es nur shared libraries gibt unter Linux. Insofern verwirrt mich deine Aussage...
Es gibt definitiv statische und shared libraries, vielleicht hat da jemand was anderes drunter verstanden. Shared = .so, Static = .a. Für die shared muss man sich ein wenig mehr Gedanken machen. Statics kannst du einfach zusammenbauen, indem du die object-files (.o) mit ar in ein Archiv stopfst:
ar rcs libtoll.a foo.o bar.o erstellt die Library libtoll.a aus den Objects foo.o und bar.o, dagegen linken kannst du dann mit -ltoll. 😉
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20095
Wohnort: Schwabenländle
|
Lunar hat geschrieben: Deswegen würde ich das Ganze zwar schon in verschiedene Dateien, Namespaces, Klassen oder in was auch immer die gewählte Sprache noch für Möglichkeiten bietet, auftrennen, aber erstmal in einem Binary belassen
Also es geht um xorg-edit und das ist ja schon länger fertig. Die Trennung ist auch schon vollzogen, daher frage ich ja jetzt, wo es darum geht das ganze zu verbreiten. ☺
Das einfachste wäre du erstellst weiterhin alles in deinem lokalen pfad, nur eben eine library und ein Frontend Programm, das eben diese verlinkt.
Hm, derzeit habe ich den Order libxorgedit/source, wo das Makefile drin ist. Wenn ich das ausführe, erhalte ich ne lib in dem Ordner. Also müßte ich dann in dem Makefile von xorg-edit/source die Lib von ../../libxorgedit/source/libxorgedit nehmen, richtig? Nur wie mache ich das mit der Einbindung der Headers? Derzeit referenziere ich das ja per ../../libxorgedit/source/devices.h z.B. Für die Deb-Variante ist das aber nicht gut, denke ich. Da wäre /usr/local/lib/include (oder wie immer auch include-files gespeichert werden) geschickte, oder? Also müßte ich das irgendwie auch allgemein in den Quellcode schreiben, denn ich kann von meinem Maintainer nicht erwarten, daß er den Quellcode ändert, damit die Headers gefunden werden. Wie macht man das am geschicktesten? Das statische Link geht ja schön einfach, das werd ich dann nehmen. So mache ich es aktuell auch (wenn auch mit einer IDE). *g* Gruß, Dee
|
haraldkl
Anmeldungsdatum: 21. Juli 2005
Beiträge: 1903
Wohnort: Würselen
|
Dee hat geschrieben: Hm, derzeit habe ich den Order libxorgedit/source, wo das Makefile drin ist. Wenn ich das ausführe, erhalte ich ne lib in dem Ordner. Also müßte ich dann in dem Makefile von xorg-edit/source die Lib von ../../libxorgedit/source/libxorgedit nehmen, richtig?
Jupp:
-L ../../libxorgedit/source -lxorgedit Dee hat geschrieben: Nur wie mache ich das mit der Einbindung der Headers? Derzeit referenziere ich das ja per ../../libxorgedit/source/devices.h z.B. Für die Deb-Variante ist das aber nicht gut, denke ich. Da wäre /usr/local/lib/include (oder wie immer auch include-files gespeichert werden) geschickte, oder?
Ich meine das passende Verzeichnis wäre /usr/local/include. Dee hat geschrieben: Also müßte ich das irgendwie auch allgemein in den Quellcode schreiben, denn ich kann von meinem Maintainer nicht erwarten, daß er den Quellcode ändert, damit die Headers gefunden werden. Wie macht man das am geschicktesten?
Und im Source-Code gibst du einfach nur den Dateinamen an, welche Verzeichnisse der Compiler nach Headern durchsuchen soll gibst du mit -I an. Dabei wird /usr/local/include glaube ich sowieso durchsucht. Falls also jemand die Library verwenden möchte und die Header nach der Installation dort liegen, müsste er sich glaube ich noch nicht mal um die Compiler-Optionen kümmern. Daher ist das für die Installation denke ich der geeignete Ort. Im eigenen Makefile würde ich aber die lokalen Pfade mit -I angeben, und so kompilieren, ohne das System zu beeinflussen. Erst mit dem weiteren Target "install" dann alles was gebraucht wird installieren...
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20095
Wohnort: Schwabenländle
|
So, klappt alles danke. ich bin zwar nicht sicher, wie der Maintainer aus den Makefiles jetzt was ordentlich bastelt, da ich kein configure-Skript habe, aber er muss ja nur eine Variable ändern. Ansonsten klappt die Paketerstellung schon ganz gut! ☺ Mal ne Frage zur Namensgebung: Was wäre denn sinnvoll? Die Basis xorg-edit nennen und die GUI wx-xorg-edit. Oder die Basis libxorgedit und die GUi xorg-edit... oder libxorg-edit (was aber blöd aussieht). Gibt es da ne Nomenklatur? Gruß, Dee
|
Lunar
Anmeldungsdatum: 17. März 2006
Beiträge: 5792
|
Dee hat geschrieben: Mal ne Frage zur Namensgebung: Was wäre denn sinnvoll? Die Basis xorg-edit nennen und die GUI wx-xorg-edit. Oder die Basis libxorgedit und die GUi xorg-edit... oder libxorg-edit (was aber blöd aussieht). Gibt es da ne Nomenklatur?
Die Basis: libxorgedit (Bibliotheken fangen immer mit lib an und ein Strich gehört imo nicht in den Namen. Der GCC gibt Bibliotheken afaik sowieso automatisch das Prefix "lib") Die Gui: frei wählbar, es sollte nur deutlich sein, das WxWidgets benutzt wird, um es später deutlich von andern Frontends abzugrenzen. Deswegen wäre WxOrgEdit (oder so ähnlich) nicht schlecht. KDE bekommt dann Kxorgedit und Gnome GXorgEdit.
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20095
Wohnort: Schwabenländle
|
Der GCC gibt Bibliotheken afaik sowieso automatisch das Prefix "lib"
Verwechsel nicht Library- und Paketname. Die Library heißt natürlich libxorgedit... Okay, macht dann wohl mehr Sinn, daß Paket ebenso zu nennen. Das andere Paket werde ich dann wohl wxXorgEdit nennen. Muss dann wohl noch ein Metapaket "xorg-edit" erstellen, welches die beiden installiert, damit die User auch updaten können.... Gruß, Dee
|
kleinweby
Anmeldungsdatum: 18. Januar 2006
Beiträge: 144
Wohnort: Dessau
|
nabend, also ich finde wxXorgEdit einwenig unpassend, denn das höst sich wie nen bestandteil von wx an. wxWindows ... Ich würds lieber es lieber xorgedit-wx nennen, daran sieht mach auch das zu.B. xorgedit-nurcess zu xorgedit hinzugehört un nicht was anderes ist. naja im is deine entscheidung, wollte nur meine meinung los werden. kleinweby
|
Apollon
Anmeldungsdatum: 27. Oktober 2004
Beiträge: 724
Wohnort: Darmstadt
|
Da hat er gar nicht mal so Unrecht, wie ich finde.
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20095
Wohnort: Schwabenländle
|
@kleinweby: Solltest Du den Machern von wxvlc mal sagen. 😉 Im Ernst: Inzwischen hab ich gemerkt, daß das absoluter Blödsinn ist, was ich da vor habe. Da die Bibliothek eh statisch ist, benötigt man die ja nicht zum Ausführen von xorg-edit, sondern nur zum Kompilieren. Daher werden ich nun doch wieder alles in ein Paket packen. Wer xorg-edit kompilieren will, kompiliert im Arciv eben erst die lib und dann die GUI. Am Ende wird aber nur die GUI gebraucht! Sollte es irgendwann ein ncurses-Oberfläche geben, kopiert diese entweder auch die LIB oder ich mache sie wirklich dynamisch, so daß alle drauf zugreifen können. Gruß, Dee
|