Hi Stefan,
hab vielen Dank für Deine Antwort.
> Das Qt Build System ist zwar an sich fein, aber ich würde lieber keine
> Abhängigkeit zu Qt in Reflex haben. Ich denke das angestrebte Layout
> lässt sich auch mit anderen Build-Systemen implementieren. Sören hatte
> mal "waf"[1] ausprobiert, das als Abhängigkeit nur Python hat, da man das
> gesamte waf (Python Scripte) in der richtigen Version einfach mit den
> Sourcen mitliefert. Das sah für mich auch sehr nett aus.
Deine Abhängigkeitsbedenken kann ich (noch) nicht verstehen. QBS ist eine
gegen Qt gelinkte Applikation, so wie waf eben Python als Laufzeitumgebung
benötigt. Man kann es unter jeder Plattform als Programm installieren. Ergo
sehe ich darin kein Problem. Waf wirkt auf den ersten Blick hochgradig
flexibel, aber auch hochgradig unverständlich, gerade auch weil ich Sören's
Experiment kenne. Cmake wäre noch ein komplexer Kandidat, welcher weit
verbreitet ist.
> Sören meinte mal, dass wir dringend eine Möglichkeit brauchen für das
> Bauen der Apps die richtigen Compiler- und Linkerswitches zu ermitteln.
> Dafür wird oft pkg-config[2] verwendet. Es gibt davon auch "bessere"
> Implementierungen, z.B. "pkgconf"[3]. Typischerweise werden diese
> Programme aber mit autoconf und make als Buildsystem kombiniert. Das
> "./configure && make && make install" würde ich ehrlich gesagt auch schön
> finden für das Reflex Framework, gerade weil es für viele Entwickler sehr
> bekannt ist. Mir ist klar, dass autoconf längst nicht so "sexy" ist wie
> die anderen erwähnten Build-Systeme.
Meinst Du, pro Toolchain die richtigen Flags für das gesamte Projekt bzw.
jedes Paket zu setzen, weil man prinzipiell unterschiedliche Compiler
verwenden können soll, bzw. verschiedene Versionen/Varianten des selben
Compilers? QBS löst das elegant mit Toolchain-Profilen, in denen man diese
projektunabhängig setzen kann. Zusätzlich lassen sich noch im Projekt
Compilerflags für jede Toolchain auf Dateiebene setzen. Das ist sehr flexibel.
Wie kompliziert ist es eigentlich, unter Windows die autotools und
pkg-config zum Laufen zu bekommen?
> Ich mache mir noch ein wenig Sorgen, dass wenn wir alles in extra
> Libraries kompilieren, die Applikation gegen eine riesige Liste Libraries
> linken muss. Süricht etwas dagegen da zusätzlich noch eine "libreflex.a"
> draus zu machen, in der einfach alles drin ist? Der Linker sollte das ja
> entsprechend strippen.
Da spricht gar nichts dagegen.
> Außerdem weiss ich noch nicht wie wir mit mehreren Versionen umgehen
> wollen. Muss der Nutzer im Reflex Build-System einfach immer ein anderes
> INSTALL-DIR mit entsprechendem Namen angeben und das in der Applikation
> dann berücksichtigen (also einen "REFLEXPATH" o.ä. setzen)? Und geben wir
> dafür sinnvolle Defaults mit? Beispiel:
> /opt/reflex/${platform}-${schedscheme}/{doc,lib,include} Wo man
> Unterordner oder Namen mit Bindestrich verwendet ist ja in erster Linie
> Geschmackssache. Ordnersturkturen flach zu halten finde ich aber gut.
Das Problem beginnt schon im Build-Ordner. Es muss verhindert werden, dass
unterschiedliche Versionen/Varianten im gleichen Ordner bauen. Jede Variante
benötigt also je einen eigenen Build- und einen Installationsordner. Wie die
Ordner benannt sind, sollte dem Benutzer und seinem jeweiligen Einsatzzweck
obliegen. Aber natürlich können wir Vorschläge beilegen.
Ich möchte auf keinen Fall als ignoranter Qt Fanboy erscheinen und QBS
durchdrücken. Ich empfand es im direkten Vergleich sehr attraktiv, weil die
verwendete Konfigurationssprache sehr einfach zu erlernen ist. Sehe ich das
richtig, dass die Ordnerstruktur mit verschiedenen Buildsystemen behandelt
werden kann? Dann können wir ja auch erst einmal umstrukturieren und dann
Buildsysteme ausprobieren.
Herzliche Grüße
Richard
