Setelah mengajukan pertanyaan ini, saya pertama-tama merumuskan persyaratan: kaku dan opsional (tetapi diinginkan) untuk sistem perakitan dan lingkungan pengembangan grafis.
Saya ingin segera mencatat bahwa ini bukan tentang menulis kode C ++ untuk beberapa platform tertentu seperti Android atau kerangka kerja, misalnya Qt, di mana semuanya siap, baik dengan membangun dan mengedit kode, tetapi tentang kode generik yang tidak terikat pada platform tertentu atau ke kerangka kerja.
Umum:
- Gratis.
- Cross-platform (setidaknya Windows dan Linux).
Membangun sistem:
- Satu tim untuk membangun platform yang berbeda.
- Rakitan tambahan dengan akun yang benar dari semua dependensi: file header dan komponen pihak ketiga yang digunakan untuk rakitan.
- Skrip perakitan hanya boleh berisi konfigurasi minimum yang diperlukan khusus untuk proyek tertentu. Logika umum build seharusnya tidak berkeliaran dari script ke script, tetapi terletak di sistem build atau plugin-nya.
- Perakitan paralel bawaan.
- Dukungan untuk berbagai toolchain (setidaknya gcc, Visual C ++, Dentang).
- Kemampuan untuk mengubah toolchain dengan biaya minimal, tanpa menulis ulang seluruh skrip build.
- Opsi build yang mudah diganti: Debug dan Release.
- Ketergantungan pada beberapa alat tingkat rendah tambahan seperti make benar-benar tidak diinginkan. Singkatnya, sistem perakitan harus mandiri.
- Integrasi sistem pembangunan dengan repositori komponen pihak ketiga seperti pkg-config atau Maven Central untuk JVM sangat diinginkan.
- Sistem build harus diperluas oleh plugins, as prosedur perakitan untuk setiap proyek tertentu mungkin lebih rumit daripada konsep konstruksi standar (pembuatan kode, misalnya, atau perakitan beberapa gambar non-standar).
- Lebih nyaman bila skrip build adalah sejenis bahasa pemrograman tingkat tinggi atau DSL yang lebih baik. Ini akan memungkinkan Anda untuk tidak terlalu mahal dan ekspresif mengubah perilaku konstruksi secara langsung dalam skrip.
- Ketika mengonfigurasi kompiler dan tautan dari skrip build, sangat nyaman ketika sistem menyediakan setidaknya abstraksi dasar: misalnya, saya ingin menambahkan makro - mengapa berpikir parameter baris perintah kompiler yang bertanggung jawab untuk ini? / D pada MSVC atau -D pada gcc - biarkan sistem build menyelesaikan sendiri rincian yang tidak penting ini.
- Integrasi yang baik dengan lingkungan pengembangan grafis (IDE).
IDE:
- Kemampuan IDE untuk "memahami" kode C ++ dengan benar. IDE harus dapat mengindeks semua file proyek, serta semua file dan definisi header dan sistem pihak ketiga (mendefinisikan, makro).
- IDE harus menyediakan kemampuan untuk menyesuaikan perintah untuk membangun proyek, serta tempat mencari file header dan definisi.
- Seharusnya secara efektif membantu dalam mengetik kode, mis. menawarkan opsi penyelesaian yang paling cocok, memperingatkan tentang kesalahan sintaks, dll.
- Menavigasi proyek besar harus nyaman, dan menemukan penggunaannya cepat dan mudah.
- Berikan banyak peluang untuk refactoring: penggantian nama, dll.
- Yang juga dibutuhkan adalah kemampuan untuk menghasilkan kode boilerplate - membuat kerangka kerja kelas baru, file header, dan file implementasi. Generasi getter / setter, definisi metode, metode virtual overloading, pola implementasi murni kelas virtual (antarmuka), dll.
- Menyoroti dan mendukung tag dokumentasi kode seperti Doxygen.
Mengingat "Daftar Keinginan" ini, saya telah mempertimbangkan beberapa sistem perakitan dan lingkungan pengembangan grafis. Ulasan singkat ini tidak dengan cara apa pun berpura-pura menjadi lengkap dan berisi penilaian subyektif saya, tetapi mungkin bagi seseorang tampaknya berguna sebagai langkah awal.
Jadikan -
[kuno] mastodon dan veteran terhormat sistem perakitan, yang semua orang masih tidak ingin pensiun, tetapi dipaksa untuk mengambil lebih banyak dan lebih banyak proyek baru. Ini adalah alat tingkat sangat rendah dengan bahasa spesifiknya sendiri, di mana untuk spasi alih-alih tab Anda langsung terancam eksekusi di tempat. Dengan menggunakan make, Anda dapat melakukan apa pun yang Anda inginkan - membangun kompleksitas apa pun, tetapi Anda harus membayarnya dengan upaya menulis skrip, serta tetap memperbarui. Akan lebih mahal untuk mentransfer logika pembangunan dari proyek ke proyek. Ada beberapa pengganti make-up modern: seperti ninja dan selai, tetapi mereka tidak mengubah esensi - ini adalah alat tingkat yang sangat rendah. Sama seperti di assembler, Anda dapat menulis apa pun yang Anda suka, tetapi apakah itu layak?
CMake -
[Abad Pertengahan] upaya pertama untuk menjauh dari detail tingkat rendah dari merek. Tapi, sayangnya, tidak mungkin untuk melangkah jauh - mesin di sini adalah merek yang sama dengan CMake yang menghasilkan file-file besar berdasarkan pada file teks lain dengan deskripsi build tingkat tinggi. Qmake bekerja dengan cara yang sama. Pendekatan ini mengingatkan saya pada fasad indah sebuah rumah kayu tua, yang dengan hati-hati dilapisi dengan plastik segar. CMake adalah sistem yang stabil dan sudah terbukti, bahkan ada integrasi dengan Eclipse, tetapi, sayangnya, itu tidak cocok untuk saya karena bertentangan dengan persyaratan yang diuraikan di awal artikel. Di Linux, semuanya tampak baik-baik saja, tetapi jika Anda perlu membangun proyek yang sama di bawah Windows menggunakan MSVC - dan saya lebih suka kompiler asli ke MinGW, file untuk NMake akan dihasilkan. Yaitu ketergantungan pada alat lain dan perintah bangun yang berbeda untuk platform lain. Dan semua ini adalah konsekuensi dari arsitektur yang agak bengkok, ketika sebagian besar pekerjaan dilakukan oleh "pembantu" lainnya.
Semut -
[renaisans] semacam klon make untuk Jawa. Terus terang, saya menghabiskan sedikit waktu untuk memeriksa Ant (dan juga Maven) sebagai sistem build untuk C ++. Dan saya langsung merasa bahwa dukungan C ++ di sini murni "untuk pertunjukan" dan tidak cukup berkembang. Terlebih lagi, bahkan dalam proyek Java, Sem sudah jarang digunakan. Sebagai bahasa scripting (dan juga untuk Maven) XML dipilih di sini - bahasa burung keji ini :). Fakta optimisme ini tidak menambah saya sama sekali untuk perendaman lebih lanjut dalam topik ini.
SCons adalah sistem build lintas platform mandiri (
era baru) yang ditulis dengan Python. SCons bekerja sama baiknya dengan Java dan C ++ build. Ketergantungan header untuk rakitan tambahan dikerjakan dengan benar (seperti yang saya mengerti, database tertentu dibuat dengan metadata build), dan pada Windows MSVC bekerja tanpa rebana. Bahasa skrip build adalah Python. Sistem yang sangat baik, dan saya bahkan ingin menyelesaikan penelitian saya tentang itu, tetapi seperti yang Anda tahu, tidak ada batasan untuk kesempurnaan, dan pemeriksaan yang lebih rinci mengungkapkan beberapa kelemahan dalam terang persyaratan di atas.
Tidak ada pengaturan abstrak untuk kompiler, jadi jika, misalnya, Anda perlu mengubah rantai alat, Anda mungkin perlu mencari tempat di skrip build untuk membuat perubahan. Makro yang sama harus ditulis dengan kondisi bersarang - jika Windows maka lakukan, jika GCC melakukannya, dll.
Tidak ada dukungan untuk artefak jarak jauh dan ketergantungan tingkat tinggi dari satu bangunan di atas yang lain.
Arsitektur umum dibangun sehingga apa yang disebut pembangun yang didefinisikan pengguna ada hampir secara terpisah dan tidak ada cara untuk menggunakan logika build yang sudah ada untuk melengkapi dengan Anda sendiri melalui plug-in sederhana. Tetapi secara keseluruhan itu adalah pilihan yang layak untuk proyek-proyek kecil.
Gradle [sekarang] - Saya sudah memiliki pengalaman positif menggunakan proyek Gradle untuk Jawa dan Kotlin dan saya punya harapan besar untuk itu.
Untuk bahasa JVM, Gradle memiliki konsep yang sangat nyaman untuk bekerja dengan perpustakaan yang diperlukan untuk membangun proyek (membangun dependensi):
- Skrip mendaftarkan alamat repositori dengan artefak: maven atau ivy - misalnya. Itu juga bisa menjadi repositori dari jenis / format lain - jika saja ada plugin untuk itu. Ini bisa berupa repositori jarak jauh, beberapa Maven Central atau hosting pribadi Anda di suatu tempat di jaringan atau hanya perwakilan lokal di sistem file.
- Juga, di bagian khusus skrip, dependensi untuk pembangunan ditunjukkan secara langsung - daftar artefak biner yang diperlukan dengan versi.
- Sebelum membangun, Gradle mencoba menyelesaikan semua dependensi dan mencari artefak dengan versi yang diberikan di semua repositori. Binari dimuat ke dalam cache dan secara otomatis ditambahkan ke build. Ini sangat mudah dan saya berharap untuk C ++, mungkin mereka melakukan hal serupa.
Pada awalnya, saya memeriksa plugin "lama" untuk dukungan C ++ - `cpp` - dan kecewa - struktur skrip tidak intuitif: model, komponen, nativespec - dan beberapa jenis mishmash dari berbagai jenis biner: baik executable dan libraries semuanya dalam satu skrip. Tidak jelas di mana harus menempatkan unit test. Struktur ini sangat berbeda dari apa yang saya gunakan untuk Java.
Tetapi ternyata ada juga plugin “baru” untuk dukungan C ++: `cpp-application` - untuk aplikasi,` cpp-library` untuk perpustakaan: statis dan dinamis, dan akhirnya `cpp-unit-test` untuk pengujian unit. Dan itulah yang saya cari! :)
Struktur folder proyek default mirip dengan proyek Java:
- src / main / cpp - folder root untuk file proyek * .cpp utama.
- src / main / header - folder untuk file header internal.
- src / main / public - folder untuk header diekspor - untuk perpustakaan.
- src / test / cpp - folder untuk file * .cpp dari unit uji.
Struktur seperti itu tidak kaku - selalu dapat diubah dalam skrip, tetapi tetap tidak perlu melakukan ini tanpa kebutuhan khusus, itu cukup masuk akal.
Omong-omong, skrip build biasanya
build.gradle , itu adalah DSL dari bahasa Groovy atau Kotlin (
build.gradle.kts ) untuk dipilih. Di dalam skrip, API Gradle dan API plugin yang ditambahkan ke skrip selalu tersedia.
Untuk perpustakaan, Anda dapat memilih jenis: statis atau dinamis (atau kumpulkan kedua opsi).
Secara default, dua opsi build dikonfigurasikan: Debug (
gradle assemble ) dan Release (
gradle assembleRelease ).
Prinsip menjalankan unit test adalah sama seperti di Jawa: tes gradle akan membangun komponen utama, kemudian tes, jika mereka berada di folder
src / test / cpp , dan kemudian jalankan aplikasi tes.
Definisi yang terkenal dapat diatur secara abstrak - Gradle sendiri akan menghasilkan opsi kompilator yang diperlukan. Ada beberapa pengaturan abstrak lainnya seperti optimasi, informasi debug, dll.
Di luar kotak, GCC, Microsoft Visual C ++, Dentang didukung.
Sistem plug-in sangat dikembangkan, dan arsitektur ekstensi nyaman - Anda dapat mengambil logika yang sudah jadi dan menghias / memperluasnya. Ada dua jenis plugin: dinamis, yang ditulis langsung di Groovy dan disematkan dalam skrip atau ditulis dalam Java (atau dalam bahasa lain dengan JVM) dan dikompilasi menjadi artefak biner. Untuk plugin, ada artifactory Gradle gratis di mana siapa saja dapat memposting plugin mereka, yang akan tersedia untuk semua orang. Yang berhasil dilakukan oleh penulis artikel ini :) tetapi lebih lanjut tentang itu nanti.
Saya ingin membahas lebih rinci tentang sistem bekerja dengan komponen biner di Gradle untuk C ++: hampir sama dengan di Jawa! Membangun dependensi bekerja hampir sama dengan yang saya jelaskan di atas.
Ambil contoh bangunan komposit:
- utils - folder perpustakaan
- app adalah folder dengan aplikasi yang menggunakan utils.
- settings.gradle - File Gradle untuk menggabungkan dua komponen ini ke dalam build komposit.
Dalam file
build.gradle dari folder aplikasi, cukup untuk menulis ketergantungan berikut:
dependencies { implementation project(':utils') }
Gradle akan melakukan sisanya! Tambahkan path ke kompiler untuk mencari file header utils dan menautkan binar perpustakaan.
Dan semua ini bekerja dengan baik baik di Linux GCC dan Windows MSVC.
Membangun tambahan, tentu saja, juga berfungsi dengan baik, dan jika Anda mengubah header di utils, aplikasi akan dibangun kembali.
Ternyata, Gradle melangkah lebih jauh dan menyadari kemampuan untuk mengunggah artefak C ++ ke Repositori Maven! Untuk melakukan ini, gunakan plugin standar `maven-publish`.
Dalam skrip, Anda perlu menentukan repositori tempat Anda ingin meletakkan artefak dan membuat gradle publish (atau gradle publishToMavenLocal untuk publikasi lokal). Gradle akan menjatuhkan proyek dan
lay out dalam format khusus - dengan mempertimbangkan versi, platform, arsitektur dan opsi bangun.
File perpustakaan biner sendiri dan file header publik diletakkan - dari folder
src / main / public .
Jelas bahwa Anda tidak dapat mengunggah artefak C ++ ke Maven Cental - tidak akan lulus pemeriksaan sistem wajib. Tetapi meningkatkan repositori Maven di jaringan sama sekali tidak sulit, dan Anda tidak perlu melakukan apa pun untuk repositori lokal - itu hanya folder pada disk.
Sekarang jika Anda ingin menggunakan perpustakaan seseorang di proyek Anda, Anda dapat menulis sesuatu seperti ini di skrip build:
repositories { maven { url = 'https://akornilov.bitbucket.io/maven' } } unitTest { dependencies { implementation 'org.bitbucket.akornilov.tools:gtest:1.8.1' } }
Dikatakan di sini bahwa untuk pengujian unit Anda perlu menggunakan versi artefak gtest 1.8.1 dari
repositori Maven .
By the way, ini adalah repositori yang sangat nyata di mana tes saya membangun Google Test v1.8.1 diposting, dibangun menggunakan Gradle untuk Windows dan Linux x86_64.
Secara alami, semua pekerjaan tingkat rendah dalam mengonfigurasi kompiler dan tautan untuk bekerja dengan komponen eksternal Gradle dilakukan. Cukuplah bagi Anda untuk menyatakan niat Anda untuk menggunakan perpustakaan ini dan itu dengan versi ini dan itu dari repositori ini dan itu.
Untuk integrasi dengan IDE, Gradle memiliki dua plugin bawaan untuk Visual Studio dan Xcode. Mereka bekerja dengan baik, kecuali bahwa plugin Visual Studio mengabaikan kode uji unit dari folder
src / test / cpp dan menghasilkan proyek hanya untuk kode utama.
Sekarang saatnya berbicara tentang IDE dan bagaimana membuat mereka berteman dengan Gradle
Eclipse CDT (2018-12R) adalah produk yang matang dan berkualitas. Jika ia berhasil mengurai proyek Anda, maka Anda beruntung - itu akan nyaman untuk diedit. Kemungkinan besar, dia bahkan akan "memahami" jenis mobil yang paling membingungkan. Tetapi jika tidak ... Maka ia akan dengan keras menekankan segala sesuatu dalam satu baris dengan garis putus-putus merah dan bersumpah dengan kata-kata buruk. Misalnya, itu tidak mencerna file header standar MSVC dan Windows SDK. Bahkan cetakan yang sama sekali tidak berbahaya digarisbawahi dengan garis putus-putus merah dan tidak dianggap sebagai sesuatu yang bermakna. Ada juga std :: string. Di Linux, dengan gcc asalnya, semuanya baik-baik saja. Tetapi bahkan ketika mencoba membuatnya untuk mengindeks proyek dari saudara Android Native, masalah dimulai. Dalam header bionik, ia point-blank menolak untuk melihat definisi size_t, dan bersama dengan semua fungsi yang menggunakannya. Mungkin, di Windows, Anda dapat memperbaiki situasi jika alih-alih file tajuk Microsoft menyelipkannya, misalnya, Cygwin atau MinGW SDK, tetapi trik ini tidak terlalu menarik bagi saya, saya masih ingin perangkat lunak tingkat ini untuk "memakan apa yang mereka berikan," dan bukan hanya bahwa dia "mencintai".
Kemungkinan untuk menavigasi, refactoring, dan menghasilkan kode templat sangat bagus, tetapi ada pertanyaan untuk penolong saat mengetik huruf: katakanlah kita mengetik beberapa karakter dari nama panjang, mengapa tidak menawarkan opsi penyelesaian? Tidak, asisten dengan sabar menunggu sampai pengguna bisa. atau -> atau ::. Saya harus terus menekan Ctrl + Space - mengganggu. Di Jawa, kekurangan yang menjengkelkan ini bisa diperbaiki dengan memilih seluruh alfabet dalam CDT sebagai pemicu, tetapi saya tidak menemukan solusi sederhana.
NetBeans 8.1 / 10.0 - Saya dulu menggunakan IDE ini untuk Java, saya dikenang sebagai perangkat lunak yang baik dan ringan dengan semua fungsionalitas yang diperlukan. Untuk C ++, ia memiliki plugin yang dikembangkan bukan oleh komunitas, tetapi langsung oleh NetBeans. Untuk proyek C ++, ada ketergantungan yang cukup sulit pada make dan gcc. Editor kode santai. Saya tidak menemukan hal yang sangat sederhana di generator kode templat: kami menambahkan metode baru di file header kelas - Anda perlu membuat badan metode dalam file cpp - tidak tahu caranya. Tingkat "pemahaman" kode adalah rata-rata, tampaknya ada sesuatu yang diuraikan, tetapi ada sesuatu yang tidak. Misalnya, iterasi pada peta dengan auto-iterator sudah sulit baginya. Dia bersumpah di makro dari Google Test. Menyesuaikan perintah build bermasalah - pada Linux dengan gcc dan menyediakan (ini terlepas dari kenyataan bahwa sistem build lain sudah digunakan) itu akan berfungsi, pada Windows itu membutuhkan MinGW, tetapi bahkan jika itu dilakukan, ia menolak untuk membangun. Secara umum, bekerja di NetBeans dengan C ++ adalah mungkin, tetapi saya tidak akan menyebutnya nyaman, saya mungkin perlu benar-benar mencintai lingkungan ini agar tidak memperhatikan berbagai luka.
KDevelop 5.3.1 - pernah dikandung sebagai alat pengembang untuk KDE (Linux), tetapi sekarang ada versi untuk Windows. Ini memiliki editor kode yang cepat dan menyenangkan dengan highlight sintaks yang indah (berdasarkan Kate). Ini tidak akan bekerja untuk merusak sistem build kiri - baginya, sistem build utama adalah CMake. Ini toleran terhadap header MSVC dan Windows SDK, dalam hal apa pun printf dan std :: string tidak benar-benar mengarah ke kebodohan seperti Eclipse CDT. Pembantu yang sangat cepat untuk menulis kode - ia menawarkan opsi penyelesaian yang baik segera setelah mengetik. Ini memiliki peluang menarik untuk menghasilkan kode templat: Anda dapat menulis templat Anda sendiri dan menaruhnya online. Saat membuat dari templat, Anda dapat terhubung ke database templat yang sudah jadi dan mengunduh yang Anda sukai. Satu-satunya hal yang mengecewakan: templat bawaan untuk membuat kelas baru berfungsi secara bengkok di bawah Windows dan Linux. Panduan untuk membuat kelas memiliki beberapa jendela tempat Anda dapat mengonfigurasi banyak hal: konstruktor mana yang diperlukan, anggota kelas mana, dll. Tetapi pada tahap akhir di bawah Windows beberapa jenis kesalahan muncul pada waktunya untuk membuat teks yang tidak mungkin dan dua file h dan cpp dibuat dalam ukuran 1 byte. Di Linux, untuk beberapa alasan, Anda tidak dapat memilih konstruktor - tab kosong, dan hanya file header yang dihasilkan dengan benar pada output. Secara umum, penyakit pada masa kanak-kanak untuk produk yang sudah matang terlihat agak remeh.
QtCreator 4.8.1 (edisi open source) - mungkin, setelah mendengar nama ini, Anda bingung bagaimana monster ini dipenjara di sini di bawah Qt dengan kit distribusi gigabyte dengan kait. Tapi ini adalah versi "ringan" dari lingkungan untuk proyek generik. Kit distribusinya hanya berbobot sekitar 150 MB dan tidak membawa hal-hal khusus untuk Qt dengan itu:
download.qt.io/official_releases/qtcreator/4.8 .
Sebenarnya, dia dapat melakukan hampir semua yang saya tulis dalam persyaratan saya dengan cepat dan benar. Ini mem-parsing header standar baik Windows dan Linux, mengkustomisasinya ke sistem build apa pun, menyarankan opsi penyelesaian, dengan mudah menghasilkan kelas baru, badan metode, memungkinkan refactoring dan navigasi kode. Jika Anda hanya ingin bekerja dengan nyaman tanpa terus-menerus memikirkan cara mengatasi masalah ini atau itu, masuk akal untuk melihat QtCreator.
Sebenarnya, masih berbicara tentang apa yang saya tidak punya cukup di Gradle untuk sepenuhnya bekerja: integrasi dengan IDE. Agar sistem dapat menghasilkan file proyek untuk IDE itu sendiri, di mana perintah untuk membangun proyek sudah akan ditulis, semua file sumber terdaftar, jalur diperlukan untuk mencari file header dan menentukan.
Untuk tujuan ini, saya menulis sebuah
plugin untuk Gradle `cpp-ide-generator` dan diterbitkan di Portal Plugin Gradle.
Plugin hanya dapat digunakan dengan `cpp-application`,` cpp-library` dan `cpp-unit-test`.
Berikut adalah contoh penggunaannya di
build.gradle :
plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-ide-generator' version '0.3' } library {
Plugin mendukung integrasi dengan semua lingkungan pengembangan grafis di atas, tetapi di blok konfigurasi plugin - ide, Anda dapat menonaktifkan dukungan untuk IDE yang tidak perlu:
kdevelop = false
Jika parameter
autoGenerate disetel ke true, file proyek untuk semua IDE yang diizinkan akan dihasilkan secara otomatis tepat saat pembuatan. Juga, dalam mode pembuatan otomatis, file proyek akan dihapus ketika build dibersihkan:
gradle clean .
Generasi tambahan didukung, mis. hanya file yang memerlukan pembaruan nyata yang akan diperbarui.
Berikut adalah daftar tujuan yang ditambahkan plugin:
- generateIde - menghasilkan file proyek untuk semua IDE yang diizinkan.
- cleanIde - hapus file proyek untuk semua IDE yang diizinkan.
- generateIde [name] - menghasilkan file proyek untuk IDE dengan nama yang diberikan (IDE harus diizinkan), misalnya generateIdeQtCreator.
- Nama yang tersedia: Eclipse, NetBeans, QtCreator, KDevelop.
- cleanIde [name] - hapus file proyek untuk IDE dengan nama yang diberikan, misalnya cleanIdeQtCreator.
Selama pembuatan, plugin “mengendus” build dan mengekstrak semua informasi yang diperlukan untuk membuat file proyek. Setelah membuka proyek, semua file sumber harus terlihat di IDE, path ke semua header harus didaftarkan, dan perintah build dasar untuk mengkonfigurasi / membangun / menghapus juga harus dikonfigurasi.
Plugin kedua yang harus saya lakukan disebut
`cpp-build-tuner` dan juga bekerja bersama-sama dengan cpp-application`,` cpp-library` dan `cpp-unit-test`.
Plugin tidak memiliki pengaturan, cukup untuk mengunggahnya:
plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-build-tuner' version '0.5' }
Plugin melakukan manipulasi kecil dengan pengaturan rantai alat (kompiler dan tautan) untuk berbagai opsi pembuatan - Debug dan Rilis. MSVC, gcc, Dentang didukung.
Ini terutama berlaku untuk MSVC, karena secara default, sebagai hasil dari rilis build, Anda akan mendapatkan "tebal", bukan binar estetika dengan informasi bazhdash dan pustaka standar yang terhubung secara statis. Saya “memata-matai” bagian dari pengaturan untuk MSVC di Visual Studio itu sendiri, yang secara default menambah proyek C ++. Untuk gcc / CLang dan MSVC, optmizations waktu tautan termasuk dalam profil Release.
Catatan: Plugin diuji dengan versi terbaru Gradle v5.2.1 dan tidak diuji kompatibilitasnya dengan versi sebelumnya.Kode sumber plugin, serta contoh sederhana menggunakan Gradle untuk pustaka: statis dan dinamis, serta aplikasi yang menggunakannya dapat dilihat: bitbucket.org/akornilov/tools next gradle / cpp.
Contoh-contoh ini juga menunjukkan cara menggunakan Google Test untuk pustaka pengujian unit.
Repositori Maven dengan Google Test v1.8.1 dibangun di Gradle (tanpa mock).UPD:Versi Windows dari
QtCreato yang lebih tua dari
4.6.2 (dan setidaknya pada saat menulis baris ini, hingga
4.10 inklusif) telah “lupa bagaimana” untuk memahami MSVC SDK. Semua std :: space digarisbawahi dalam warna merah dan menolak untuk mengindeks. Oleh karena itu, saat ini, versi 4.6.2 paling cocok untuk bekerja di bawah Windows.
Versi baru dari plugin
cpp-build-tuner v1.0 telah dirilis (dan
cpp-ide-generator v0.5 adalah perbaikan kecil).
1) Menambahkan blok konfigurasi ke
cpp-build-tuner .
buildTuner { lto = false gtest = '1.8.1' libraries { common = ['cutils.lib'] windows = ['ole32', 'user32'] linux = ['pthread', 'z'] } libDirs.common = ['../build/debug', '../release'] }
lto (boolean) - Mengaktifkan atau menonaktifkan LTO untuk rilis rilis. Diaktifkan secara default.
gtest (string) - Menambahkan dukungan Google Test untuk pengujian unit. Saat ini hanya versi 1.8.1 yang didukung untuk GCC, MinGW-W64, dan MSVC.
perpustakaan (wadah) - daftar perpustakaan untuk dihubungkan. Di dalam wadah ada tiga bidang (daftar baris):
common - perpustakaan untuk platform apa pun,
windows - hanya untuk Windows dan
linux - hanya untuk Linux.
libDirs (container) - daftar folder untuk mencari perpustakaan dengan linker. Struktur wadah sama dengan daftar perpustakaan.
2) Menambahkan kemampuan untuk menjalankan aplikasi untuk aplikasi-
cpp-application . Plugin menambahkan tugas tambahan ke proyek untuk ini:
run ,
runDebug (sama seperti
run ) dan
runRelease . Tugas tergantung pada
assemble ,
assembleDebug dan
assembleRelease masing-masing.
Seperti plugin Java Application standar, Anda dapat melewatkan parameter baris perintah saat startup:
gradle run --args="arg1 arg2 ..." .
UPDSehubungan dengan perubahan plugin hosting, grup diubah:
plugins { id 'loggersoft.cpp-build-tuner' version '1.1' id 'loggersoft.cpp-ide-generator' version '0.5' }
Alamat proyek baru:
gradle-cpp.sourceforge.ioDokumentasi:
sourceforge.net/p/gradle-cpp/wiki/cpp-build-tunersourceforge.net/p/gradle-cpp/wiki/cpp-ide-generator