Làm cách nào để quản lý đúng các phụ thuộc cho dự án C / C ++?


11

Tôi có một dự án sử dụng 3-4 thư viện C / C ++ mã nguồn mở khác nhau.

Tôi đã xây dựng các thư viện này cho một số nền tảng và đăng ký bao gồm các tệp và lib tĩnh cho các nền tảng khác nhau trong dự án của tôi.

Tuy nhiên, tôi đấu tranh với một vài vấn đề. Tất cả các dự án này là xung quanh quản lý phụ thuộc. Và tôi đang tìm kiếm lời khuyên thực hành tốt nhất.

1) Làm thế nào để tôi biết chính xác những gì tôi sử dụng?

Tôi không có cách nào để có được một phiên bản lib tĩnh. Kết quả là, tôi cần theo dõi bằng cách nào đó phiên bản của lib tĩnh tôi đang sử dụng (có thể là SHA của một cam kết mà nó được xây dựng)?

Điều này đặc biệt quan trọng khi tôi cần tìm ra khi nào cần nâng cấp các lib này.

2) Làm thế nào để tôi tái tạo bản dựng?

Tôi có thể đã vật lộn để xây dựng một số thư viện cụ thể cho một nền tảng cụ thể. Tôi phải mất một lúc để tìm ra nó.

Lần sau khi tôi cần xây dựng cùng một thư viện có thể là trong nửa năm nữa (khi đó tôi sẽ cần nâng cấp vì bất kỳ lý do gì. Tuy nhiên, vào lúc đó, tôi chắc chắn sẽ không nhớ bất cứ điều gì và môi trường mà nó được xây dựng sẽ còn lâu

3) Tôi có nên rẽ nhánh các thư viện này để có một bản sao của mã nguồn không?

Đây là một mối quan tâm ít hơn. Tuy nhiên, nó vẫn là một mối quan tâm. Thật tuyệt khi đảm bảo rằng các bản dựng có thể tái tạo (và loại yêu cầu mã nguồn).

Câu trả lời:


5

Bạn có thực sự cần phải luôn luôn sử dụng một phiên bản chính xác của thư viện phụ thuộc không? Có phải nó được viết xấu / nó có phá vỡ API của nó với mỗi lần tăng nhỏ trong phiên bản không?

Nếu bạn xem các dự án nguồn mở, các configuretập lệnh xây dựng ( phần lớn) của chúng sẽ kiểm tra xem các thư viện khác nhau có hiện diện hay không và có lỗi hay không. Nó cũng đủ linh hoạt để cho phép người dùng liên kết với phiên bản mới hơn của thư viện (có thể cung cấp nhiều sửa lỗi / bảo mật hơn phiên bản cũ) và cũng không thực thi liên kết tĩnh hoặc liên kết động.

Nếu bạn thực sự cần các bản dựng có thể tái tạo, thì bạn cũng nên chú ý đến phiên bản chính xác của trình biên dịch và đó là các thư viện chuẩn, thậm chí có thể là hệ điều hành. Trong trường hợp này, có một máy xây dựng với môi trường chính xác mà bạn yêu cầu, theo tôi, tốt hơn là kiểm tra các thư viện được biên dịch trong kho lưu trữ mã nguồn.


2
Tôi không nghĩ rằng tôi cần sử dụng phiên bản chính xác. Tuy nhiên, tôi cần biết cái nào tôi đang sử dụng. Ví dụ: nếu ai đó thấy rằng OpenSSL 1.1.0b có lỗ hổng lớn, tôi biết rõ hơn rằng tôi sử dụng OpenSSL 1.1.0b hay 1.1.0c
Victor Ronin

Về khả năng tái tạo xây dựng, đó có lẽ là mối quan tâm thứ yếu của tôi.
Victor Ronin

3

Làm thế nào để tôi biết chính xác những gì tôi sử dụng?

Nếu tệp bao gồm hoặc tệp lib chưa có số phiên bản, hãy thêm tệp văn bản "version.txt" (chứa số phiên bản) vào từng thư mục lib và kiểm tra nó vào VCS của bạn, cùng với tệp lib và bao gồm tệp . Tuy nhiên, nếu bạn phiên bản nguồn lib đầy đủ (điểm 3), rất có thể đã có tệp mã nguồn chứa số phiên bản, do đó không cần phải duy trì riêng cho trường hợp này.

Làm thế nào để tôi tái tạo bản dựng?

Cố gắng tự động hóa càng nhiều càng tốt. Sử dụng tập lệnh, tệp tạo tệp hoặc tệp của các công cụ xây dựng yêu thích của bạn. Đặt tất cả điều này dưới sự kiểm soát nguồn. Nếu có các bước thủ công cần thiết, hãy viết chi tiết vào một tệp văn bản (ví dụ: readme_build.txt) và đặt nó dưới sự kiểm soát nguồn.

Tôi có nên rẽ nhánh các thư viện này để có một bản sao của mã nguồn không?

Bạn nên có một bản sao của mã nguồn , nhưng chỉ rẽ nhánh nếu cần thiết (ví dụ: nếu bạn vấp phải một lỗi khẩn cấp và tác giả ban đầu không thể sửa nó trong thời gian hạn chế của bạn). Hoặc, nếu các tác giả sử dụng một môi trường trình biên dịch khác với bạn và cần phải thực hiện một số thay đổi để làm cho lib hoạt động trong môi trường của bạn. Tuy nhiên, lưu ý rằng mỗi thay đổi đối với mã nguồn ban đầu trong ngã ba của bạn có thể khiến việc tích hợp các bản cập nhật sau này trở nên khó khăn hơn.

Tuy nhiên, tôi khuyên bạn nên lấy một bản sao của mã nguồn gốc (không được xử lý) của các lib bạn đang sử dụng. Điều đó sẽ cho phép bạn rẽ nhánh hoặc duy trì lib sau này nếu cần thiết, ngay cả khi người bảo trì ban đầu quyết định thu hồi các nguồn lib từ web công cộng.


Vì vậy, câu trả lời là "làm điều này bằng tay" :) Tôi đã hy vọng rằng ai đó sẽ nói ... oh ... có một công cụ cho việc đó :) Khi bạn nói "bản sao của mã nguồn", bạn chỉ cần lấy một tập tin tar với nguồn và kết xuất nó trong kiểm soát nguồn?
Victor Ronin

1
@VictorRonin: không, câu trả lời là "hãy để VCS của bạn xử lý tất cả những gì nó có thể làm cho bạn" và "tự động hóa nhiều nhất có thể bằng các công cụ xây dựng tiêu chuẩn". Bạn là người chọn một phiên bản cụ thể và bạn là người cần xác định các bước xây dựng, liên kết và bao gồm các tham chiếu cho môi trường của bạn. Thủ tục tiêu chuẩn để thể hiện những sự khinh miệt này là thông qua các tập lệnh, tệp thực hiện, tệp dự án, v.v.
Doc Brown

... Và cách bạn có được lib hoặc mã nguồn thư viện tùy thuộc vào cách người bảo trì / nhà cung cấp cung cấp nó. Có thể một quả bóng nhựa, có thể bằng cách truy cập trực tiếp vào trung tâm git, có thể là gói nuget.
Doc Brown
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.