Was Sie eingeben und wie Sie ein C ++ - Projekt zusammenstellen

Nachdem ich diese Frage gestellt hatte, formulierte ich zunächst die Anforderungen: starr und optional (aber wünschenswert) für das Montagesystem und die grafische Entwicklungsumgebung.
Ich möchte sofort darauf hinweisen, dass es nicht darum geht, C ++ - Code für eine bestimmte Plattform wie Android oder ein Framework zu schreiben, zum Beispiel Qt, wo alles fertig ist, sowohl beim Erstellen als auch beim Bearbeiten von Code, sondern um generischen Code, der nicht an eine bestimmte Plattform gebunden ist oder zum Rahmen.

Allgemein:

• Kostenlos.
• Plattformübergreifend (mindestens Windows und Linux).

Build-System:

• Ein einziges Team, das auf verschiedenen Plattformen aufbaut.
• Inkrementelle Assembly mit der korrekten Berücksichtigung aller Abhängigkeiten: Header-Dateien und Komponenten von Drittanbietern, die für die Assembly verwendet werden.
• Das Assemblerskript sollte nur die für ein bestimmtes Projekt erforderliche Mindestkonfiguration enthalten. Die allgemeine Logik des Builds sollte nicht von Skript zu Skript wechseln, sondern befindet sich im Build-System oder seinen Plugins.
• Eingebaute Parallelmontage.
• Unterstützung für verschiedene Toolchains (mindestens gcc, Visual C ++, CLang).
• Die Möglichkeit, die Toolchain mit minimalen Kosten zu ändern, ohne das gesamte Build-Skript neu schreiben zu müssen.
• Leicht umschaltbare Build-Optionen: Debug und Release.
• Abhängigkeiten von einigen zusätzlichen Low-Level-Tools wie make sind völlig unerwünscht. Mit einem Wort, das Montagesystem sollte autark sein.
• Die Integration des Build-Systems in Repositorys von Komponenten von Drittanbietern wie pkg-config oder Maven Central für die JVM ist äußerst wünschenswert.
• Das Build-System muss durch Plugins erweiterbar sein Das Montageverfahren für jedes spezifische Projekt kann komplizierter sein als das Standardkonstruktionskonzept (z. B. Codegenerierung oder Montage eines nicht standardmäßigen Bildes).
• Dies ist praktisch, wenn das Build-Skript eine Programmiersprache auf hoher Ebene oder sogar noch besser DSL ist. Auf diese Weise können Sie das Verhalten der Konstruktion nicht sehr kostspielig und ausdrücklich direkt im Skript ändern.
• Wenn Sie den Compiler und den Linker über das Build-Skript konfigurieren, ist es sehr praktisch, wenn das System zumindest grundlegende Abstraktionen bereitstellt: Ich möchte beispielsweise ein Makro hinzufügen - warum sollte man sich überlegen, welcher Compiler-Befehlszeilenparameter dafür verantwortlich ist? / D unter MSVC oder -D unter gcc - Lassen Sie das Build-System diese unwichtigen Details selbst auflösen.
• Gute Integration in grafische Entwicklungsumgebungen (IDEs).

IDE:

• Die Fähigkeit der IDE, C ++ - Code richtig zu "verstehen". Die IDE muss in der Lage sein, alle Projektdateien sowie alle Header-Dateien und Definitionen von Drittanbietern und Systemen (Definitionen, Makros) zu indizieren.
• Die IDE sollte die Möglichkeit bieten, Befehle zum Erstellen eines Projekts anzupassen sowie nach Header-Dateien und Definitionen zu suchen.
• Es sollte effektiv bei der Eingabe von Code helfen, d. H. bieten die am besten geeigneten Abschlussoptionen, warnen vor Syntaxfehlern usw.
• Das Navigieren in einem großen Projekt sollte bequem sein und schnell und einfach Verwendung finden.
• Bieten Sie ausreichend Möglichkeiten für das Refactoring: Umbenennen usw.
• Außerdem wird die Möglichkeit benötigt, Boilerplate-Code zu generieren - ein neues Klassenframework, eine neue Headerdatei und eine neue Implementierungsdatei zu erstellen. Generierung von Gettern / Setzern, Methodendefinitionen, Überladen virtueller Methoden, Implementierungsmuster rein virtueller Klassen (Schnittstellen) usw.
• Hervorheben und Unterstützen von Code-Dokumentations-Tags wie Doxygen.

Im Lichte dieser "Wunschliste" habe ich verschiedene Montagesysteme und grafische Entwicklungsumgebungen betrachtet. Diese kurze Rezension gibt in keiner Weise vor, vollständig zu sein, und enthält meine subjektiven Einschätzungen, aber vielleicht erscheint sie jemandem als ersten Schritt nützlich.

Machen Sie - [die Antike] zu einem Mastodon und einem wohlverdienten Veteranen der Montagesysteme, die immer noch nicht in den Ruhestand gehen wollen, sondern immer mehr neue Projekte annehmen müssen. Dies ist ein sehr einfaches Tool mit einer eigenen Sprache, bei dem für ein Leerzeichen anstelle eines Tabs sofort die Ausführung vor Ort droht. Mit make können Sie alles tun, was Sie wollen - einen Build beliebiger Komplexität, aber Sie müssen dafür bezahlen, um ein Skript zu schreiben und es auf dem neuesten Stand zu halten. Es wird auch teuer sein, die Logik des Builds von Projekt zu Projekt zu übertragen. Es gibt einige moderne Make-up-Ersatzstoffe wie Ninja und Marmelade, aber sie ändern nichts an der Essenz - dies sind sehr einfache Werkzeuge. Genau wie im Assembler können Sie alles schreiben, was Sie möchten, aber lohnt es sich?

CMake - [Mittelalter] der erste Versuch, sich von den Details der Marke auf niedriger Ebene zu lösen. Leider war es nicht möglich, weit zu gehen - die Engine hier ist dieselbe Marke, für die CMake riesige Make-Dateien basierend auf einer anderen Textdatei mit einer höheren Build-Beschreibung generiert. Qmake funktioniert ähnlich. Dieser Ansatz erinnert mich an die schöne Fassade eines alten Holzhauses, das sorgfältig mit frischem Kunststoff ummantelt wurde. CMake ist ein stabiles und bewährtes System, es gibt sogar eine integrierte Integration in Eclipse, aber leider hat es mir nicht gepasst, da es einem Teil der am Anfang des Artikels festgelegten Anforderungen widerspricht. Unter Linux scheint alles in Ordnung zu sein, aber wenn Sie dasselbe Projekt unter Windows mit MSVC erstellen müssen - und ich den nativen Compiler MinGW vorziehe, werden die Dateien für NMake generiert. Das heißt, Abhängigkeiten von einem anderen Tool und andere Build-Befehle für eine andere Plattform. Und all dies ist eine Folge einer etwas krummen Architektur, wenn der Großteil der Arbeit von anderen "Helfern" erledigt wird.

Ant - [Renaissance] eine Art Make-Klon für Java. Ehrlich gesagt habe ich ziemlich viel Zeit damit verbracht, Ant (sowie Maven) als Build-System für C ++ zu überprüfen. Und ich hatte sofort das Gefühl, dass die C ++ - Unterstützung hier nur "zur Schau" und nicht ausreichend entwickelt ist. Darüber hinaus wird Ant auch in Java-Projekten bereits selten eingesetzt. Als Skriptsprache (sowie für Maven) wird hier XML gewählt - diese abscheuliche Vogelsprache :). Diese Tatsache des Optimismus hat mich überhaupt nicht dazu gebracht, weiter in das Thema einzutauchen.

SCons ist ein eigenständiges, plattformübergreifendes Build-System, das in Python geschrieben wurde. SCons funktioniert sowohl mit Java- als auch mit C ++ - Builds gleich gut. Die Abhängigkeiten der Header für die inkrementelle Assembly werden korrekt ausgearbeitet (nach meinem Verständnis wird eine bestimmte Datenbank mit den Build-Metadaten erstellt), und unter Windows funktioniert MSVC ohne Tamburin. Die Build-Skriptsprache ist Python. Ein sehr anständiges System, und ich wollte sogar meine Forschung darüber beenden, aber wie Sie wissen, gibt es keine Grenzen für die Perfektion, und eine detailliertere Untersuchung ergab einige Nachteile im Lichte der oben genannten Anforderungen.

Es gibt keine abstrakten Einstellungen für den Compiler. Wenn Sie beispielsweise die Toolchain ändern müssen, müssen Sie möglicherweise nach Stellen im Build-Skript suchen, um Änderungen vorzunehmen. Dieselben Makros müssen mit verschachtelten Bedingungen geschrieben werden - wenn es Windows ist, dann mach es, wenn es GCC ist, mach es usw.

Remote-Artefakte und die Abhängigkeit eines Builds von einem anderen auf hoher Ebene werden nicht unterstützt.

Die allgemeine Architektur ist so aufgebaut, dass die sogenannten benutzerdefinierten Builder fast isoliert existieren und es keine Möglichkeit gibt, die bereits vorhandene Build-Logik zu verwenden, um sie durch ein einfaches Plug-In durch Ihre eigene zu ergänzen. Insgesamt ist es jedoch eine gute Wahl für kleine Projekte.

Gradle [anwesend] - Ich hatte bereits positive Erfahrungen mit Gradle für Java- und Kotlin-Projekte und hatte große Hoffnungen darauf.

Für JVM-Sprachen hat Gradle ein sehr praktisches Konzept für die Arbeit mit den Bibliotheken, die zum Erstellen eines Projekts erforderlich sind (Build-Abhängigkeiten):

• Das Skript registriert die Adressen von Repositorys mit Artefakten: Maven oder Ivy - zum Beispiel. Es kann auch ein Repository eines anderen Typs / Formats sein - wenn es nur ein Plugin dafür gäbe. Dies kann ein Remote-Repository, ein Maven Central oder Ihr persönliches Hosting irgendwo im Netzwerk oder nur ein lokaler Mitarbeiter im Dateisystem sein.
• In einem speziellen Abschnitt des Skripts werden die Abhängigkeiten für die Erstellung direkt angegeben - eine Liste der erforderlichen binären Artefakte mit Versionen.
• Vor dem Erstellen versucht Gradle, alle Abhängigkeiten aufzulösen, und sucht in allen Repositorys nach Artefakten mit den angegebenen Versionen. Binärdateien werden in den Cache geladen und automatisch zum Build hinzugefügt. Das ist sehr praktisch und ich hatte gehofft, dass sie für C ++ vielleicht etwas Ähnliches gemacht haben.

Zuerst habe ich das "alte" Plugin für die C ++ - Unterstützung - "cpp" - ausgecheckt und war enttäuscht - die Skriptstruktur ist nicht intuitiv: Modell, Komponente, Nativespec - und eine Art Mischmasch aus verschiedenen Arten von Binärdateien: sowohl ausführbare Dateien als auch Bibliotheken in einem Skript. Es ist nicht klar, wo Unit-Tests platziert werden sollen. Diese Struktur war sehr unterschiedlich zu dem, was ich für Java verwendet habe.

Es stellte sich jedoch heraus, dass es auch "neue" Plugins für die C ++ - Unterstützung gibt: "cpp-application" - für Anwendungen, "cpp-library" für Bibliotheken: statisch und dynamisch und schließlich "cpp-unit-test" für Unit-Tests. Und das war es, wonach ich gesucht habe! :) :)

Die Standardstruktur des Projektordners ähnelt dem Java-Projekt:

• src / main / cpp - der Stammordner für die Hauptprojektdateien * .cpp .
• src / main / headers - Ordner für interne Header-Dateien.
• src / main / public - Ordner für exportierte Header - für Bibliotheken.
• src / test / cpp - Ordner für * .cpp- Dateien der Testeinheit.

Eine solche Struktur ist nicht starr - sie kann immer im Skript geändert werden, aber es ist nicht notwendig, dies ohne besondere Notwendigkeit zu tun, es ist durchaus vernünftig.

Übrigens ist das Build-Skript normalerweise build.gradle . Dies sind die DSLs von Groovy oder Kotlin ( build.gradle.kts ) zur Auswahl. Innerhalb des Skripts sind die Gradle-API und die APIs der dem Skript hinzugefügten Plugins immer verfügbar.

Für Bibliotheken können Sie den Typ auswählen: statisch oder dynamisch (oder beide Optionen erfassen).
Standardmäßig sind zwei Build-Optionen konfiguriert: Debug ( Gradle Assemble ) und Release ( Gradle AssembleRelease ).

Das Prinzip des Ausführens von Unit-Tests ist dasselbe wie in Java: Gradle Test erstellt die Hauptkomponente und dann die Tests, sofern sie sich im Ordner src / test / cpp befinden , und führt dann die Testanwendung aus.

Die berüchtigten Definitionen können abstrakt festgelegt werden - Gradle selbst generiert die erforderlichen Compileroptionen. Es gibt mehrere abstraktere Einstellungen wie Optimierung, Debugging-Informationen usw.

Standardmäßig werden GCC, Microsoft Visual C ++ und CLang unterstützt.

Das Plug-In-System ist sehr entwickelt und die Erweiterungsarchitektur ist praktisch - Sie können vorgefertigte Logik verwenden und sie dekorieren / erweitern. Es gibt zwei Arten von Plugins: Dynamic, die direkt in Groovy geschrieben und in ein Skript eingebettet oder in Java (oder in einer anderen Sprache mit der JVM) geschrieben und zu binären Artefakten kompiliert werden. Für Plugins gibt es eine kostenlose Gradle-Artifactory, in der jeder sein Plugin posten kann, das jedem zur Verfügung steht. Was vom Autor dieses Artikels erfolgreich gemacht wurde :) aber dazu später mehr.
Ich möchte näher auf das System der Arbeit mit Binärkomponenten in Gradle für C ++ eingehen: Es ist fast das gleiche wie in Java! Builds von Abhängigkeiten funktionieren fast genauso wie oben beschrieben.

Nehmen Sie zum Beispiel einen zusammengesetzten Build:

• utils - Bibliotheksordner
• App ist der Ordner mit der Anwendung, die Utils verwendet.
• settings.gradle - Gradle-Datei zum Kombinieren dieser beiden Komponenten zu einem zusammengesetzten Build.

In der Datei build.gradle aus dem App-Ordner reicht es aus, die folgende Abhängigkeit zu schreiben:

dependencies { implementation project(':utils') } 

Gradle erledigt den Rest! Fügen Sie dem Compiler einen Pfad hinzu, um nach Utils-Header-Dateien zu suchen und die Bibliotheks-Binärdatei zu verknüpfen.

Und das alles funktioniert sowohl unter Linux GCC als auch unter Windows MSVC gleich gut.
Inkrementelle Builds funktionieren natürlich auch hervorragend. Wenn Sie die Header in Utils ändern, wird die App neu erstellt.

Wie sich herausstellte, ging Gradle noch weiter und erkannte die Möglichkeit, C ++ - Artefakte in das Maven-Repository hochzuladen! Verwenden Sie dazu das Standard-Plugin "Maven-Publish".

Im Skript müssen Sie das Repository angeben, in dem Sie Ihr Artefakt ablegen und Gradle veröffentlichen möchten (oder Gradle PublishToMavenLocal für die lokale Veröffentlichung). Gradle wird das Projekt stürzen und
Layout in einem speziellen Format - unter Berücksichtigung der Version, Plattform, Architektur und Build-Option.

Die binären Bibliotheksdateien selbst und die öffentlichen Header-Dateien werden aus dem Ordner src / main / public angelegt .

Es ist klar, dass Sie keine C ++ - Artefakte auf Maven Cental hochladen können - die obligatorischen Systemprüfungen werden nicht bestanden. Das Erhöhen des Maven-Repositorys im Netzwerk ist jedoch überhaupt nicht schwierig, und Sie müssen nichts für das lokale Repository tun - es ist nur ein Ordner auf der Festplatte.

Wenn Sie nun die Bibliothek einer anderen Person in Ihrem Projekt verwenden möchten, können Sie Folgendes in das Build-Skript schreiben:

  repositories { maven { url = 'https://akornilov.bitbucket.io/maven' } } unitTest { dependencies { implementation 'org.bitbucket.akornilov.tools:gtest:1.8.1' } } 

Hier heißt es, dass Sie für Unit-Tests das gtest-Artefakt Version 1.8.1 aus dem Maven-Repository verwenden müssen .

Übrigens ist dies ein sehr reales Repository, in dem mein Testbuild Google Test v1.8.1 veröffentlicht wird, der mit Gradle für Windows und Linux x86_64 erstellt wurde.

Natürlich werden alle einfachen Arbeiten zur Konfiguration des Compilers und Linkers für die Arbeit mit der externen Komponente von Gradle durchgeführt. Es reicht aus, wenn Sie Ihre Absicht erklären, eine solche und eine solche Bibliothek mit einer solchen und einer solchen Version aus einem solchen und einem solchen Repository zu verwenden.

Für die Integration in die IDE verfügt Gradle über zwei integrierte Plugins für Visual Studio und Xcode. Sie funktionieren gut, außer dass das Visual Studio-Plugin den Unit-Test-Code aus dem Ordner src / test / cpp ignoriert und ein Projekt nur für den Hauptcode generiert.

Jetzt ist es Zeit, über die IDE zu sprechen und wie man sie mit Gradle befreundet

Eclipse CDT (2018-12R) ist ein ausgereiftes und qualitativ hochwertiges Produkt. Wenn er es geschafft hat, Ihr Projekt erfolgreich zu analysieren, haben Sie Glück - es ist bequem zu bearbeiten. Höchstwahrscheinlich wird er sogar die verwirrendsten Arten von Autos "verstehen". Aber wenn nicht ... Dann wird er alles in einer Reihe mit einer rot gepunkteten Linie heftig betonen und in schlechten Worten schwören. Beispielsweise werden Standard-MSVC- und Windows SDK-Headerdateien nicht verarbeitet. Selbst ein völlig harmloser Ausdruck wird mit einer rot gepunkteten Linie unterstrichen und nicht als etwas Sinnvolles wahrgenommen. Es gab auch std :: string. Unter Linux mit seinem nativen gcc ist alles in Ordnung. Aber selbst als er versuchte, ihn dazu zu bringen, das Projekt von einer Schwester Android Native zu indizieren, begannen Probleme. In bionischen Headern weigerte er sich aus nächster Nähe, die Definition von size_t und alle Funktionen, die sie verwendeten, zu sehen. Wahrscheinlich können Sie unter Windows die Situation korrigieren, wenn ihm anstelle von Microsoft-Header-Dateien beispielsweise Cygwin oder MinGW SDK ausfallen, aber diese Tricks sind für mich nicht sehr interessant. Ich möchte immer noch, dass Software dieser Stufe „isst, was sie gibt“ und nicht nur dass er "liebt".
Die Möglichkeiten zum Navigieren, Refactoring und Generieren von Vorlagencode sind wunderbar, aber es gibt Fragen an den Helfer beim Eingeben von Buchstaben: Nehmen wir an, wir geben ein paar Zeichen aus einem langen Namen ein. Warum bieten wir keine Vervollständigungsoptionen an? Nein, der Assistent wartet geduldig, bis der Benutzer dazu kommt. oder -> oder ::. Ich muss ständig Strg + Leertaste drücken - nervig. In Java konnte dieser lästige Mangel behoben werden, indem das gesamte Alphabet im CDT als Auslöser ausgewählt wurde, aber ich fand keine einfache Lösung.





NetBeans 8.1 / 10.0 - Ich habe diese IDE für Java verwendet. Ich wurde als gute und leichte Software mit allen erforderlichen Funktionen in Erinnerung behalten. Für C ++ gibt es ein Plugin, das nicht von der Community, sondern direkt von NetBeans entwickelt wurde. Bei C ++ - Projekten besteht eine ziemlich starke Abhängigkeit von make und gcc. Der Code-Editor ist gemächlich. Ich habe im Vorlagencode-Generator keine sehr einfache Sache gefunden: Wir fügen der Klassen-Header-Datei eine neue Methode hinzu - Sie müssen den Methodenkörper in einer CPP-Datei generieren - sie weiß nicht wie. Der Grad des "Verstehens" des Codes ist durchschnittlich, es scheint, dass etwas analysiert wird, aber etwas nicht. Zum Beispiel ist es für ihn bereits schwierig, auf einer Karte mit einem Auto-Iterator zu iterieren. Er schwört auf Makros von Google Test. Das Anpassen des Build-Befehls ist problematisch - unter Linux mit gcc und verfügbar machen (dies trotz der Tatsache, dass bereits ein anderes Build-System verwendet wird) funktioniert es, unter Windows wird MinGW benötigt, aber selbst wenn dies der Fall ist, wird das Erstellen abgelehnt. Im Allgemeinen ist das Arbeiten in NetBeans mit C ++ möglich, aber ich würde es nicht als komfortabel bezeichnen. Ich muss diese Umgebung wahrscheinlich wirklich lieben, um die verschiedenen Wunden nicht zu bemerken.





KDevelop 5.3.1 - wurde früher als Entwicklertool für KDE (Linux) konzipiert, jetzt gibt es eine Version für Windows. Es hat einen schnellen und unterhaltsamen Code-Editor mit wunderschöner Syntaxhervorhebung (basierend auf Kate). Es wird nicht funktionieren, das linke Build-System zu manipulieren - für ihn ist das Haupt-Build-System CMake. Es ist tolerant gegenüber MSVC- und Windows SDK-Headern, auf jeden Fall führen printf und std :: string nicht gerade zu einem Stupor wie einem Eclipse CDT. Ein sehr schneller Helfer zum Schreiben von Code - er bietet fast sofort während der Eingabe gute Vervollständigungsoptionen. Es bietet eine interessante Möglichkeit, Vorlagencode zu generieren: Sie können Ihre eigene Vorlage schreiben und online stellen. Wenn Sie aus einer Vorlage erstellen, können Sie eine Verbindung zur Datenbank mit vorgefertigten Vorlagen herstellen und die gewünschte herunterladen. Das einzige, was Sie verärgert hat: Die integrierte Vorlage zum Erstellen einer neuen Klasse funktioniert sowohl unter Windows als auch unter Linux schief. Der Assistent zum Erstellen einer Klasse verfügt über mehrere Fenster, in denen Sie viele Dinge konfigurieren können: Welche Konstruktoren werden benötigt, welche Mitglieder der Klasse usw. In der letzten Phase unter Windows tritt jedoch rechtzeitig ein Fehler auf, um den Text zu erkennen, der unmöglich ist, und zwei Dateien h und cpp werden in der Größe von 1 Byte erstellt. Unter Linux können Sie aus irgendeinem Grund keine Konstruktoren auswählen. Die Registerkarte ist leer und nur die Header-Datei wird in der Ausgabe korrekt generiert. Im Allgemeinen sehen Kinderkrankheiten für ein so ausgereiftes Produkt irgendwie leichtfertig aus.





QtCreator 4.8.1 (Open Source Edition) - Nachdem Sie diesen Namen gehört haben, sind Sie wahrscheinlich ratlos darüber, wie dieses Monster hier unter Qt mit einem Gigabyte-Distributionskit mit Haken eingesperrt wurde. Dies ist jedoch eine "leichte" Version der Umgebung für generische Projekte. Das Distributionskit wiegt nur etwa 150 MB und enthält keine Qt-spezifischen Dinge: download.qt.io/official_releases/qtcreator/4.8 .
Eigentlich kann er fast alles, worüber ich in meinen Anforderungen geschrieben habe, schnell und richtig machen. Es analysiert die Standard-Header von Windows und Linux, passt sie an jedes Build-System an, schlägt Abschlussoptionen vor, generiert bequem neue Klassen, Methodenkörper, ermöglicht Refactoring und Code-Navigation. Wenn Sie nur bequem arbeiten möchten, ohne ständig darüber nachzudenken, wie Sie dieses oder jenes Problem lösen können, ist es sinnvoll, sich QtCreator anzusehen.





Eigentlich bleibt es zu besprechen, was ich in Gradle nicht genug hatte, um vollständig zu arbeiten: Integration in die IDE. Damit das System Projektdateien für die IDE selbst generieren kann, in die die Befehle zum Erstellen des Projekts bereits geschrieben wurden, werden alle Quelldateien aufgelistet, Pfade werden benötigt, um nach Header-Dateien zu suchen und zu bestimmen.

Zu diesem Zweck habe ich ein Plugin für Gradle `cpp-ide-generator` geschrieben und im Gradle Plugin Portal veröffentlicht.

Das Plugin kann nur mit "cpp-application", "cpp-library" und "cpp-unit-test" verwendet werden.
Hier ist ein Beispiel für die Verwendung in build.gradle :

  plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-ide-generator' version '0.3' } library { // Library specific parameters } // Configuration block of plugin: ide { autoGenerate = false eclipse = true qtCreator = true netBeans = true kdevelop = true } 

Das Plugin unterstützt die Integration in alle oben genannten grafischen Entwicklungsumgebungen. Im Plugin-Konfigurationsblock können Sie jedoch die Unterstützung für unnötige IDEs deaktivieren:

  kdevelop = false 

Wenn der Parameter autoGenerate auf true gesetzt ist, werden Projektdateien für alle zulässigen IDEs direkt während des Builds automatisch generiert. Im automatischen Generierungsmodus werden Projektdateien auch gelöscht, wenn der Build bereinigt wird: gradle clean .

Inkrementelle Erzeugung wird unterstützt, d.h. Es werden nur die Dateien aktualisiert, für die ein echtes Update erforderlich ist.

Hier ist eine Liste der Ziele, die das Plugin hinzufügt:

• generateIde - Generiert Projektdateien für alle zulässigen IDEs.
• cleanIde - Löscht Projektdateien für alle zulässigen IDEs.
• generateIde [name] - Generiert Projektdateien für die IDE mit dem angegebenen Namen (IDE muss zulässig sein), z. B. generateIdeQtCreator.
• Verfügbare Namen: Eclipse, NetBeans, QtCreator, KDevelop.
• cleanIde [Name] - Löscht Projektdateien für die IDE mit dem angegebenen Namen, z. B. cleanIdeQtCreator.

Während der Generierung „schnüffelt“ das Plugin am Build und extrahiert daraus alle erforderlichen Informationen, um Projektdateien zu erstellen. Nach dem Öffnen des Projekts in der IDE sollten alle Quelldateien sichtbar sein, die Pfade zu allen Headern sollten registriert sein und die grundlegenden Build-Befehle - build / clear - sind konfiguriert.

Das zweite Plugin, das ich machen musste, heißt "cpp-build-tuner" und funktioniert auch zusammen mit "cpp-application", "cpp-library" und "cpp-unit-test".

Das Plugin hat keine Einstellungen, es reicht gerade aus, um es hochzuladen:

  plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-build-tuner' version '0.5' } 

Das Plugin führt kleine Manipulationen mit den Einstellungen der Toolchains (Compiler und Linker) für verschiedene Build-Optionen durch - Debug und Release. MSVC, gcc, CLang werden unterstützt.

Dies gilt insbesondere für MSVC, da Sie als Ergebnis des Release-Builds standardmäßig eine "fette", nicht ästhetische Binärdatei mit Bazhdash-Informationen und einer statisch verknüpften Standardbibliothek erhalten. Ich habe einen Teil der Einstellungen für MSVC in Visual Studio selbst "ausspioniert", das standardmäßig zu seinen C ++ - Projekten hinzugefügt wird. Sowohl für gcc / CLang als auch für MSVC sind Verbindungszeitoptimierungen im Release-Profil enthalten.

Hinweis: Plugins wurden mit der neuesten Version von Gradle v5.2.1 getestet und nicht auf Kompatibilität mit früheren Versionen getestet.

Die Quellcodes der Plugins sowie einfache Beispiele für die Verwendung von Gradle für Bibliotheken: statisch und dynamisch sowie die Anwendung, die sie verwendet, können angezeigt werden: bitbucket.org/akornilov/tools next gradle / cpp.

Die Beispiele zeigen auch, wie Sie Google Test für Unit-Test-Bibliotheken verwenden.

Maven Repository mit Google Test v1.8.1 in Gradle (ohne Mock).

UPD:

Windows-Versionen von QtCreato r, die älter als 4.6.2 sind (und zumindest zum Zeitpunkt des Schreibens dieser Zeilen bis einschließlich 4.10 ), haben „vergessen“, wie das MSVC SDK zu verstehen ist. Der gesamte std :: space ist rot unterstrichen und weigert sich zu indizieren. Daher ist Version 4.6.2 derzeit am besten für die Arbeit unter Windows geeignet.

Eine neue Version des Plugins cpp-build-tuner v1.0 wurde veröffentlicht (und cpp-ide-generator v0.5 sind geringfügige Verbesserungen).
1) Konfigurationsblock zum cpp-build-tuner hinzugefügt.

 buildTuner { lto = false gtest = '1.8.1' libraries { common = ['cutils.lib'] windows = ['ole32', 'user32'] linux = ['pthread', 'z'] } libDirs.common = ['../build/debug', '../release'] } 

lto (boolean) - Aktiviert oder deaktiviert LTO für den Release-Build. Standardmäßig aktiviert.

gtest (Zeichenfolge) - Fügt Google Test-Unterstützung für Komponententests hinzu . Derzeit wird nur Version 1.8.1 für GCC, MinGW-W64 und MSVC unterstützt.

Bibliotheken (Container) - Eine Liste von Bibliotheken zum Verknüpfen. Innerhalb des Containers gibt es drei Felder (Liste der Zeilen): common - Bibliotheken für jede Plattform, windows - nur für Windows und linux - nur für Linux.

libDirs (Container) - Eine Liste von Ordnern zum Durchsuchen von Bibliotheken mit einem Linker. Die Container-Struktur entspricht der Bibliotheksliste.

2) Es wurde die Möglichkeit hinzugefügt, Anwendungen für cpp-application auszuführen. Das Plugin fügt dem Projekt zusätzliche Aufgaben hinzu: run , runDebug (wie run ) und runRelease . Aufgaben hängen von assemble , assembleDebug bzw. assembleRelease ab.
Wie beim Standard-Java-Anwendungs-Plugin können Sie beim Start gradle run --args="arg1 arg2 ..." : gradle run --args="arg1 arg2 ..." .

UPD

Im Zusammenhang mit der Änderung der Hosting-Plugins wurde die Gruppe geändert:

 plugins { id 'loggersoft.cpp-build-tuner' version '1.1' id 'loggersoft.cpp-ide-generator' version '0.5' } 

Neue Projektadresse: gradle-cpp.sourceforge.io

Dokumentation:
sourceforge.net/p/gradle-cpp/wiki/cpp-build-tuner
sourceforge.net/p/gradle-cpp/wiki/cpp-ide-generator