Bagaimana cara mengelola dependensi untuk proyek C / C ++ dengan benar?


11

Saya punya proyek yang menggunakan 3-4 open source C / C ++ library yang berbeda.

Saya membangun pustaka ini untuk beberapa platform dan memeriksa menyertakan file dan lib statis untuk berbagai platform dalam proyek saya.

Namun, saya berjuang dengan beberapa masalah. Semua proyek ini berada di sekitar manajemen ketergantungan. Dan saya mencari saran praktik terbaik.

1) Bagaimana saya tahu apa yang sebenarnya saya gunakan?

Saya tidak punya cara untuk mendapatkan versi lib statis. Akibatnya, saya perlu entah bagaimana melacak versi lib statis yang saya gunakan (mungkin SHA dari komit yang dibangunnya)?

Ini sangat penting ketika saya harus mencari tahu kapan harus meningkatkan lib ini.

2) Bagaimana cara mereproduksi bangunan?

Saya bisa berjuang untuk membangun beberapa perpustakaan khusus untuk platform tertentu. Butuh beberapa saat untuk mengetahuinya.

Waktu berikutnya ketika saya perlu membangun perpustakaan yang sama bisa dalam setengah tahun (ketika saya perlu memperbarui dengan alasan apa pun. Namun, pada saat itu, saya tidak akan ingat apa pun dan lingkungan tempat perpustakaan itu dibangun. akan lama hilang.

3) Haruskah saya garpu perpustakaan ini untuk memiliki salinan kode sumber?

Ini adalah keprihatinan yang lebih rendah. Namun, ini masih menjadi perhatian. Sangat menyenangkan untuk memastikan bahwa build dapat direproduksi (dan semacam itu membutuhkan kode sumber).

Jawaban:


5

Apakah Anda benar-benar harus selalu menggunakan versi tepat dari pustaka dependen? Apakah ini ditulis dengan buruk / apakah itu merusak API dengan setiap peningkatan kecil dalam versi?

Jika Anda melihat proyek-proyek open-source, configureskrip build-nya ( sebagian besar) memeriksa apakah berbagai pustaka hadir dan membuat kesalahan jika tidak. Ini juga cukup fleksibel untuk memungkinkan pengguna untuk menautkan ke versi perpustakaan yang lebih baru (yang mungkin menyediakan lebih banyak perbaikan bug / keamanan daripada yang lebih tua) dan juga tidak menerapkan tautan statis atau dinamis.

Jika Anda benar-benar membutuhkan bangunan yang dapat direproduksi, maka Anda juga harus memperhatikan versi yang tepat dari kompiler dan pustaka standarnya, bahkan mungkin sistem operasinya. Dalam hal ini, memiliki mesin build dengan lingkungan yang tepat yang Anda butuhkan, menurut pendapat saya, lebih baik daripada memeriksa di perpustakaan yang dikompilasi dalam repositori kode sumber.


2
Saya tidak berpikir bahwa saya perlu menggunakan versi yang tepat. Namun, saya perlu tahu yang mana yang saya gunakan. Sebagai contoh, jika seseorang menemukan bahwa OpenSSL 1.1.0b memiliki kerentanan besar, saya lebih baik tahu apakah saya menggunakan OpenSSL 1.1.0b atau 1.1.0c
Victor Ronin

Mengenai reproduktifitas build, itu mungkin perhatian kedua saya.
Victor Ronin

3

Bagaimana saya tahu apa yang sebenarnya saya gunakan?

Jika file include atau libs sudah tidak berisi nomor versi, tambahkan file teks "version.txt" (berisi nomor versi) sendiri ke setiap folder lib dan periksa ke dalam VCS Anda, bersama dengan lib dan sertakan file . Namun, jika Anda versi sumber lib penuh (titik 3), kemungkinan besar sudah ada file kode sumber yang berisi nomor versi, jadi tidak perlu mempertahankan sendiri untuk kasus ini.

Bagaimana cara mereproduksi bangunan?

Cobalah untuk mengotomatisasi sebanyak yang Anda bisa. Gunakan skrip, makefile, atau file alat build favorit Anda. Letakkan ini semua di bawah kendali sumber. Jika ada langkah-langkah manual yang diperlukan, tuliskan rinciannya ke dalam file teks (misalnya, readme_build.txt) dan letakkan itu di bawah kendali sumber juga.

Haruskah saya garpu perpustakaan ini untuk memiliki salinan kode sumber?

Anda harus memiliki salinan kode sumber , tetapi bercabang hanya jika perlu (misalnya, jika Anda menemukan bug yang mendesak, dan penulis asli tidak dapat memperbaikinya dalam batasan waktu Anda). Atau, jika penulis menggunakan lingkungan kompiler berbeda dari Anda, dan perlu untuk membuat beberapa perubahan untuk membuat lib bekerja di lingkungan Anda. Namun, ketahuilah bahwa setiap perubahan pada kode sumber asli di garpu Anda kemungkinan besar mempersulit untuk mengintegrasikan pembaruan di lain waktu.

Namun demikian saya merekomendasikan untuk mendapatkan salinan kode sumber asli (tidakorkas) dari libs yang Anda gunakan. Itu akan memungkinkan Anda untuk bercabang atau memelihara lib nanti jika diperlukan, bahkan jika pengelola asli memutuskan untuk mencabut sumber lib dari web publik.


Jadi, jawabannya adalah "lakukan ini secara manual" :) Saya berharap seseorang akan mengatakan ... oh ... ada alat untuk itu :) Ketika Anda mengatakan "salinan kode sumber" yang Anda maksud, dapatkan saja file tar dengan sumber dan membuangnya dalam kontrol sumber?
Victor Ronin

1
@VictorRonin: tidak, jawabannya adalah "biarkan VCS Anda menangani semua yang bisa dilakukannya untuk Anda", dan "mengotomatisasi sebanyak yang Anda bisa menggunakan alat bantu pembuatan standar". Andalah yang memilih versi tertentu, dan Andalah yang perlu mendefinisikan langkah-langkah pembangunan, tautan & sertakan referensi untuk lingkungan Anda. Prosedur standar untuk memanifestasikan despendensi ini adalah melalui skrip, makefile, file proyek dll.
Doc Brown

... dan bagaimana Anda mendapatkan lib atau kode sumber perpustakaan tergantung pada bagaimana pengelola / vendor menyediakannya. Mungkin bola tar, mungkin dengan akses langsung ke git hub, mungkin paket nuget.
Doc Brown
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.