cmake für plugins?

Zitat von chriszero

Moin,
Spricht eigentlich was dagegen cmake für VDR Plugins einzusetzen?

Klingt so als würdest du damit denjenigen ein Bein stellen, die es gewohnt sind im VDR-Source-Tree ihre plugins zu bauen.

Distributoren dürfte das relative egal sein.

Gerald

Zitat von chriszero

hmm, ist ein Argument...

Die Frage ist nur: Kümmert dich das?

Mir wäre es egal. Bei mir heißt es "Friss oder stirb"

Gerald

Ich mag cmake sogar sehr gerne. Das ist im Normalfall viel übersichtlicher als jegliche Makefiles
Habe mir extra wegen CLion eine CMakeLists.txt für den VDR gebastelt.

Ist das Zufall, dass ich heute Nachmittag hier CLion erwähnt habe und du das jetzt testest?

Kann einem Unwissenden mal der Unterschied gezeigt werden? Also ein cmake-File im Vergleich mit einem normalen Makefile?

Lars.

Hier gibt es ein Beispielprojekt: https://github.com/rhoelzel/make_cmake

Wenn ich das richtig sehe, ist cmake ein Tool, um plattformunabhängig Makefiles usw. zu generieren.
Warum würde das für ein Linux-only-Projekt Sinn machen?

Lars.

Ich weiß nicht, ich bin bislang nur bei einigen KODI-Paketen damit in Kontakt gekommen, die mit dem Debian Multiarch-Ansatz Probleme hatten ihre Bibliotheken dort zu platzieren, wo sie erwartet wurden...

Bei Kodi verstehe ich es, das läuft ja auf vielen Plattformen. Und dann für jede ein entsprechendes Makefile zu pflegen, ist aufwendig.

Lars.

cmake ist nicht einfach ein Ersatz für make, es benutzt ja sogar selbst make. Es ist ein Ersatz für die Autotools. Ich finde cmake hässlich, eine seltsame Script-Sprache, aber die Autotools sind noch hässlicher.

Gerald

Hallo Forum,

sorry für den späten Beitrag, ich glaube ich kann da einige Infos liefern. CMake ist ein makefile Generator. Wer qmake kennt, weiß was es ungefähr tut. Es ist aber nicht auf C/C++ und QT beschränkt und kann viel mehr als qmake. Ich arbeite seit 5 Jahren mit cmake und sehe folgende Vorteile:

1. Man beschreibt das Projekt auf hoher Ebene und nicht auf Build-Target-Ebene => Die "Makefiles" sind viel kompakter, meist weniger als eine Bildschirmseite.
2. Die Abhängigkeiten werden vollständig erfasst.
3. Out of tree builds. Ich kann in einem Tree gleich für mehrere Platformen bauen. Das wird auch durch den CMakeCache erledigt.
4. Der Cache. Man kann den Build konfigurieren und so auch Beta-Code in den Quellen verteilen. Das lässt sich dann beim Build einschalten. Auch für spez. Libraryversionen etc. einsetzbar.
5. Configuration des Builds wie configure. Methoden im Dateien, Bibliotheken etc zu suchen (find_file, find_library, find_package) Packages sind für die gängisten Bibliotheken dabei (/usr/share/cmake-<ver>/Modules)
6. Package-Konzept - man kann es mögen oder auch nicht.
7. Alles in einem einzigen Dateiformat beschrieben
8. Jedes Verzeichnis hat sein eigenes "Makefile"
9. Properties, um auch mal tiefer eingreifen zu können.
10. Funktions-Konzept zum Erstellen von projektspezifischen Funktionen.
11. Ein Konzept um eigene Targets (Dateien und .phony) einzubringen.
11. Die Dokumentation ist ausreichend.
12. Es ist ein deutsches Projekt.
13. Alle Artefakte sind Textdateien. Keine geheimen Dateiformate.
14. Gute Integration in kdevelop - wer es mag-.
15. Ausflüge in externe Tools werden weitestgehend vermieden.

Was ist unschön:

1. Die Syntax ist, wie schon erwähnt, etwas gewöhnungsbedürftig, was aber immer zutrifft, wenn man sich nicht auskennt. Sie ist aber auf jeden Fall wenig intuitiv.
2. Die Doku hilft am Anfang nicht weiter. Man bekommt immer nur das was man schon weiß als Antworten.
3. Man muss die Variablen und Properties kennen um schwierige Aufgaben lösen zu können.
4. Der Start viel mir ziemlich schwer. Ich habe entsprechend viele Dinge falsch angefangen.

Vielleicht hilft das noch dem Einen oder Anderen....

Fehlt noch ein dmake das die cmake config erzeugt *duck*