Dedupe - Architektur

Proggen.org - Lernprojekt: Duplikatefinder
Antworten
Benutzeravatar
fat-lobyte
Beiträge: 1398
Registriert: Sa Jul 05, 2008 12:23 pm
Wohnort: ::1
Kontaktdaten:

Dedupe - Architektur

Beitrag von fat-lobyte » Fr Jul 22, 2011 12:05 pm

Tag.

Ich hab an den letzte Tagen am Build-System geschraubt und hatte einige Freiheiten. Diese Entscheidungen hab ich erstmal alleine getroffen, doch jetzt würde ich gerne eine kleine Diskussion anstoßen.
Es geht darum wie Dedupe aufgebaut ist, aber vor allem auf welche Art es gebaut werden soll.

Was ich meine ist:
Welche Komponenten bekommen ne eigene Bibliothek? Sollen zum Beispiel "Unterkomponenten" als extra Target kompiliert werden, oder sollen einfach die Quellen in die nächsthöhere Ebene dazugenommen werden?

Welche bibliothek wird shared (.so, .dll, .dynlib) gebaut? Wollen wir das überhaupt? Meiner Meinung wäre das schon interessant, da wir im endeffekt mehrere Interfaces (CLI, Ncurses, wx/Qt) haben werden. Da würde ich gerne Code-duplikation vermeiden, und das was möglich ist als Shared Library zu bauen, und nur Interface-spezifische komponenten statisch hineinzulinken.

Zurzeit werden die Komponenten (filesearch, dataholding, hash, kernel) alle zu einer Shared Library zusammengelinkt (dedupe-kernel), und diese Bibliothek dann gegen die Interfaces gelinkt. Geht das klar?

Sollten die Abhängigkeiten (SQLite3, Boost.Filesystem, Boost.System) statisch oder dynamisch gelinkt werden?

Zusätzlich wäre auch noch zu klären, ob standardmäßig überhaupt dynamische Bibliotheken erstellt werden sollen, oder ob man dazu erst noch eine Option hinzufügen muss. Wie sehen eure Präferenzen aus?

  • Status auf Linux:
    Hier ist so ziemlich alles Grün. Diskussionswürdig ist höchstens noch, ob Bibliotheken
    Vielleicht auch noch interessant wäre es, irgendwann die SOVERSION der Shared Bibliotheken tatsächlich zu Pflegen, sollte denn die API (vielleicht sogar die ABI?) irgendwann mal Stabil werden.
  • Status auf Windows:
    • MinGW32:
      Grün, bis auf einen Bug den ich zurzeit gar nicht verstehe (Dedupe::FileInfo::GetHash(unsigned long long const&) beim linken nicht gefunden, WTF?!)
    • MinGW64:
      Noch nict ausprobiert
    • MSVC 2010, 32 Bit
      Das hier ist interessanter.
      Das war auch der Grund wieso ich von mehreren .dll's auf nur dedupe-kernel.dll umgestellt habe. Anscheinend haben wir eine Zirkuläre Abhängigkeit drinnen: dedupe-hash braucht dedupe-filesearch und dedupe-filesearch braucht dedupe-hash. Das gibt fehler beim Linken von .dll's, da zur linkzeit alle Symbole aufgelöst sein müssen. Ich glaube ehrlichgesagt, dass dedupe-hash nichts von dedupe-filesearch wissen sollte. das würde für eine klare hirarchische struktur sorgen.

      :!: Das hier ist ein wichtiger Punkt:
      Sollten wir tatsächlich eine (oder mehrere) .DLL's erstellen wollen, müssen wir uns entscheiden welche Symbole exportiert werden. Dann können wir das dem Compiler über a) Linker flags (bitte nicht!!) b) über ein .def file oder c) über __decl(dllexport)'s im Code mitteilen.
      Ich persönlich bevorzuge c), da man hier über relativ simple Präprozessorlogik alle fälle berücksichtigen kann. b) finde ich nicht so gut, da das file jedes mal geändert werden müsste, wenn sich die API ändert. Außerdem würde ich dazu sowieso erstmal manuell die __decl(dllexport)'s einfügen, kompilieren, das generierte .def file editieren und dann einchecken. Steh ich nicht so drauf.
      Deswegen bräuchte ich Feedback: Welche funktionen gehören exportiert? Ich schlage hier vor, einfach alle public methoden der Dedupe::Kernel Klasse zu exportieren. Was meint ihr?
    • MSVC 2010, 64 Bit
      Nicht ausprobiert, sollte aber keine Unterschiede machen.
    • MSVC 2005, MSVC 2008
      Noch nicht getestet. Sollte aber gemacht werden.
    • Welche anderen Compiler sollen überhaupt noch unterstützt werden?
  • Status auf Mac: keine Ahnung!! Das sollte irgendjemand mal ausprobieren.
  • Status auf BSD: keine Ahnung!! Das sollte irgendjemand mal ausprobieren.
    Hat jeman BSD? Sehe ich das richtig, dass der unterschied zu Linux klein ist? Weiß jemand von schwierigkeiten die auftreten könnten?
mfg, und sorry für zuviel text,
fat-lobyte
Haters gonna hate, potatoes gonna potate.

Benutzeravatar
cloidnerux
Moderator
Beiträge: 3123
Registriert: Fr Sep 26, 2008 4:37 pm
Wohnort: Ram (Gibts wirklich)

Re: Dedupe - Architektur

Beitrag von cloidnerux » Fr Jul 22, 2011 1:06 pm

dedupe-hash braucht dedupe-filesearch und dedupe-filesearch braucht dedupe-hash. Das gibt fehler beim Linken von .dll's, da zur linkzeit alle Symbole aufgelöst sein müssen. Ich glaube ehrlichgesagt, dass dedupe-hash nichts von dedupe-filesearch wissen sollte. das würde für eine klare hirarchische struktur sorgen.
Hatte ich iwo in einer der Diskussion so ähnlich erwähnt, nur nicht in dem Kontext.
Es ist im Grunde nur 1 Funktion, die in eine andere Klasse wandern müsste.
Spreche ich mich mal mit Bebu ab.
Redundanz macht wiederholen unnötig.
quod erat expectandum

Benutzeravatar
Bebu
Beiträge: 562
Registriert: Mi Okt 21, 2009 6:19 pm
Wohnort: In der Nähe von Salzburg - Bin aber kein Österreicher!

Re: Dedupe - Architektur

Beitrag von Bebu » Fr Jul 22, 2011 8:53 pm

fat-lobyte hat geschrieben: Das war auch der Grund wieso ich von mehreren .dll's auf nur dedupe-kernel.dll umgestellt habe. Anscheinend haben wir eine Zirkuläre Abhängigkeit drinnen: dedupe-hash braucht dedupe-filesearch und dedupe-filesearch braucht dedupe-hash. Das gibt fehler beim Linken von .dll's, da zur linkzeit alle Symbole aufgelöst sein müssen. Ich glaube ehrlichgesagt, dass dedupe-hash nichts von dedupe-filesearch wissen sollte. das würde für eine klare hirarchische struktur sorgen.
cloidnerux hat geschrieben: Hatte ich iwo in einer der Diskussion so ähnlich erwähnt, nur nicht in dem Kontext.
Es ist im Grunde nur 1 Funktion, die in eine andere Klasse wandern müsste.
Spreche ich mich mal mit Bebu ab.
Ich möchte kurz was herausstellen, das vielleicht durch die aktuelle Ordnerstruktur etwas untergegangen ist. Von dedupe-filesearch muss bis auf den Kernel und die NCurses GUI niemand wissen. Allerdings liegen in diesem Ordner auch die Files für die FileInfo Klasse und die muss so gut wie allen anderen bekannt sein, weil derzeit alle Module darauf operieren. Es wäre zum Beispiel eine Überlegung wert FileInfo zum Kernel zu packen. Es ist möglich, Hash komplett herauszulösen, allerdings futtere ich filesearch mit FileInfos, und auch Dataholding wird schlussendlich mit FileInfos bzw. FileStreams gefüttert. Das stellt bisher das interne Austauschformat für Dateien dar und ich finde es etwas unlogisch, Hash aus diesem Muster auszuklammern. Sollte das trotz allem gewünscht sein, dann lässt sich diese Funktion auch in den Kernel auslagern, dann ist Hash außen vor. In dem Fall würde ich daraus aber zwei Funktionen machen, eine die ein einzelnes FileInfo hasht und eine, die einen Filestream hashen kann. Das werde ich voraussichtlich in der Datenhaltung benötigen.
Wer immer nach dem Unerreichbaren jagt, der wird irgendwann auf die Schnauze fallen!

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Dedupe - Architektur

Beitrag von Xin » Di Jul 26, 2011 11:35 am

fat-lobyte hat geschrieben:Was ich meine ist:
Welche Komponenten bekommen ne eigene Bibliothek?
Da wir einiges an GUIs basteln, können wir überlegen, diese als Libs auszulagern. Außerdem ist es interessant, weil Dedupe nicht nur Dedupe ist, sondern auch ein Show-Projekt.
Alles andere sollte imho in der ausführbaren Datei landen.

Das ist ja derzeit wohl auch der angedachte Weg.
fat-lobyte hat geschrieben:Zurzeit werden die Komponenten (filesearch, dataholding, hash, kernel) alle zu einer Shared Library zusammengelinkt (dedupe-kernel), und diese Bibliothek dann gegen die Interfaces gelinkt. Geht das klar?

Sollten die Abhängigkeiten (SQLite3, Boost.Filesystem, Boost.System) statisch oder dynamisch gelinkt werden?
Gerade bei Windows ist es interessant, wenn Das Programm ohne weitere Abhängigkeiten laufen kann. Andererseits können wir auch absichtlich Abhängigkeiten konstruieren, um den Installationsvorgang zu demonstrieren.
fat-lobyte hat geschrieben:Anscheinend haben wir eine Zirkuläre Abhängigkeit drinnen: dedupe-hash braucht dedupe-filesearch und dedupe-filesearch braucht dedupe-hash.

Das müssen wir auflösen - unabhängig von den Libs. Das ist einfach nur schlecht.
fat-lobyte hat geschrieben:[*]Status auf Mac: keine Ahnung!! Das sollte irgendjemand mal ausprobieren.
Das landet wohl bei mir :-/
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Antworten