QtPods - Einfaches Sharing von Qt code

[jacobdawid]

Hallo Leute,

ich hab vor einiger Zeit aus einem mich selbst betreffenden Problem ein Projekt ins Leben gerufen (wow, das klingt hochtrabend also ich hab angefangen, es zu entwickeln), welches es Qt Entwicklern ermöglicht, ihren Code besonders einfach zu paketieren und mit anderen zu teilen. Dabei wollte ich so viele vorhanden Technologien nutzen wir möglich.

Die Grundidee ist folgende: Es existiert ein qmake Sammelprojekt, wovon eines das Hauptprojekt darstellt und alle anderen als statisch gelinkte Bibliotheken gegen eure eigentlich Anwendung gelinkt werden (sogenannte "Pods", der Name ist an die ähnlichen Pods aus dem Projekt "Cocoapods" für iOS Anwendungen angelehnt). Diese Pods werden als git submodules (also als verlinkte git-Projekte) und qmake Unterprojekte eingebunden. Das coole ist: Es erfordert keinerlei "Spezialinformationen", die Struktur eines mit QtPods erstellten Projekts ist nicht von QtPods abhängig. Es gibt ein QtPods Core Pod, welches alle zentralen Operationen mit diesen Pods bündelt, darauf aufbauend ein Kommandozeilentool und ein grafisches Tool (welches schon ein ganzes Stück weiter ist).


fotos kostenlos

Das Projekt wird auf github gehostet:
https://github.com/qt-pods/qt-pods

Ich suche nach Meinungen und euren Erfahrungen mit dem Projekt, aber nach Entwickler, die auch gern ihren Code so teilen und für alle verfügbar machen möchten.

[RHBaum]

Grundlegend find ich die Idee witzig.
Durch nen kurzen Ausflug in die Java Welt war ich eh von dem Maven / Artefakt Konzept begeistert.
Aber in C++ wirst recht schnell wieder auf den Boden der Tatsachen zurückgeholt.

paar Problemchen seh ich bei sowas generell.

1. Lizenz
Wenn ich richtig verstehe wie das zulinken funktionieren soll, ist es absolut "Wurscht" ob nen Projekt unter GPL oder LGPL steht. Da du statisch linkst, bist du von Anwenderseite eh auf GPL festgelegt.

2. Buildgeneratoren:
nicht jeder verwendet qmake, ich würd mal fast behaupten, das es nicht mal die Mehrheit ist.
Vielleicht war ne Erweiterung um nen cmake Zweig sinnvoll.

3. Versionsabhaengigkeiten
Ich seh keine Qt Versionierung ... ab und an ändert sich doch was in QT ... meist kommt nur was hinzu. Das darf man bei dem Konzept aber nicht verwenden ?

4. andere Abhaengigkeiten (das Hauptproblem)
Was passiert wenn ich in einem Module ("POD") abhängigkeiten zu ner 3rd party library habe ... wird das ueber den Buildgenerator nach oben gereicht ?
Zumindest sollte da was bei der Beschreibung des Modules stehen. Grad das Abhaengigkeitsmanagment ist ja der Teufel bei c++ und nicht grad trivial.
Aber nur Module generieren die von Qt und der standard runtime abhängen dürfen schränkt die Sache dann doch ziemlich stark ein oder ?

P.S. ich programmier hauptsächlichst beruflich (closed source), ich dürft sowas eh nicht nutzen, mir nur "Anregungen" holen ^^

Ciao ...

[jacobdawid]

Hallo RHBaum,

ich geh mal einzeln auf deine Fragen ein:

zu 1.) Zunächst einmal wird nicht statisch gegen die Qt Libraries gelinkt, sondern nur gegen die Pods (die ihrerseits statisch oder dynamisch gegen Qt gelinkt werden können). Natürlich ist die Lizenz des jeweiligen Pods zu beachten. Für Projekte, die die Rechte ihrer Nutzer einschränken, bleiben dann tatsächlich nur die MIT/New BSD Varianten.

Das QtPods-Projekt selbst steht unter GPL. Das bezieht sich aber nicht auf die damit erstellten/verwalteten Projekte.

zu 2.) Derzeit ist qmake der Standard. Auch wenn dies oft behauptet wird, entpuppt es sich letztendlich immer als falsch, dass es eine technische Notwendigkeit gäbe, qmake durch cmake zu ersetzen. Meist spielen da die (subjektiven) Vorlieben der Entwickler eine gewichtige Rolle. Ich habe bereits geprüft, ob es nicht möglich wäre, trotzdem cmake zu integrieren. Die Lösungen sind nicht zufriedenstellend (ich gehe da gerne nochmal im Detail drauf ein, das würde den Post hier aber sprengen).

zu 3.) Man kann jedes Pod in jeder Version (über git) vorhalten. Sollte man nicht auf die nächste Qt Version upgraden wollen (auf diversen Gründen), dann kann man das Pod in der aktuellen Version halten. Diese Informationen sind bei den jeweiligen Projekten zu bekommen, aber du hast natürlich recht: Schön wäre es, eine Kompatibilitätsliste für Qt-Version für einen raschen Überblick zu bekommen.

zu 4.) Das liegt in der Hand der jeweiligen Pods. Sie müssen spezifizieren, ob sie weitere Abhängigkeiten haben. Dies sollte sich natürlich in engen Grenzen halten, aber wenn jemand Qt-spezifisch entwickelt baut er ja ohnehin auf ein application development framework auf. Es kann also passieren, dass einige extern libs notwendig sind, die sollten sich bei halbwegs vernünftiger Entwicklungsweise pro Pod an einer Hand abzählen lassen.