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?
- MinGW32:
- 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?
fat-lobyte