Quản lý phụ thuộc giống Maven cho C ++? [đóng cửa]

Giả sử tôi có một dự án C ++ được chia thành nhiều dự án con. Tất cả các tiểu dự án đều tạo ra một DLL và các nhóm nhà phát triển khác nhau làm việc trên mỗi tiểu dự án. Bây giờ nếu tôi muốn xây dựng dự án chính, có cách nào để tránh phải tự mình xây dựng tất cả các dự án phụ không?

Tóm lại, tôi đang tìm kiếm thứ gì đó thực hiện quản lý phụ thuộc (tức là đối với tệp nhị phân và tiêu đề) theo cách tương tự như Maven làm cho Java.

Trên thực tế, tôi đã cố gắng sử dụng Maven cho việc này nhưng điều này khá phức tạp vì tôi phải tạo các gói theo cách thủ công và khá thường xuyên, Maven bỏ lỡ những thay đổi gần đây nhất. Ngoài ra, việc chạy biên dịch cũng hơi khó vì tôi phải gọi NAnt từ bên trong Maven (tôi sử dụng tính năng của NAnt để xây dựng các giải pháp Visual Studio trực tiếp).

Bất kỳ gợi ý và ý tưởng về cách làm điều này?

Câu trả lời ban đầu : Tôi khuyên bạn nên sử dụng CMake. Nó là một trình tạo tệp đa nền tảng (tạo cả các dự án Visual Studio hoặc Eclipse CDT).

http://www.cmake.org/

Tôi đã có trải nghiệm thực sự tốt với nó. Điều tốt nhất tôi thích về nó là khả năng tạo ra cấu trúc dự án chung. Vì vậy, thông thường bạn có thể bao gồm tra cứu các dự án con cho các bài kiểm tra đơn vị, v.v. mà không cần thay đổi tập lệnh mỗi lần.

Họ cũng có rất nhiều mô-đun về cách tìm các thư viện bản dựng được cài đặt sẵn, cần thiết cho dự án (như Boost, QT, v.v.)

Cập nhật : Trong thời gian đó, đã có một số nỗ lực để giới thiệu quản lý gói cho C ++. Một số dự án đáng xem:

• conan.io tích hợp với các công cụ xây dựng chính:
  • CMake
  • Visual Studio
  • Makefile
  • XCode
  • ...
• cpm dựa trên CMake ( Lưu ý rằng CPM không được duy trì tích cực.)
• Buckaroo

Lưu ý như được chỉ ra bởi @RAM trong nhận xét cpm không còn được duy trì tích cực.

Đối với quản lý phụ thuộc, nó tồn tại một dự án mới (đó là một công ty khởi nghiệp) đang triển khai loại công cụ này: https://github.com/biicode (một trình quản lý phụ thuộc C ++). Bạn có thể thêm các phụ thuộc của mình và nó sẽ hoạt động.

Hiện tại, tên dự án là conan.io , họ đã được mua lại bởi JFrog .

CẬP NHẬT: Dự án đã chết ... Thật không may, có vẻ như công ty khởi nghiệp không thể có đủ khách hàng trả phí bảo hiểm, nhưng máy chủ có vẻ đang hoạt động tốt ...

CẬP NHẬT2: Có vẻ như có một dự án thay thế: conan.io (cảm ơn @mucaho)

Tôi đề xuất các hệ thống xây dựng cấp cao sau:

• Maven Nar Plugin: Sử dụng Maven cho các dự án C / C ++
• Plugin Gradle cpp : Đây là một cách dễ dàng hơn, nhưng nó hiện đang được ấp ủ, đây là các tính năng chính và lộ trình .
• Conan là cách tiếp cận C ++ nhiều hơn, nó đa nền tảng và nó hỗ trợ hầu hết các hệ thống xây dựng C ++ phổ biến.

Nếu bạn chỉ muốn quản lý phụ thuộc, hãy thử Ivy , nó tích hợp độc đáo với Ant (và tôi cho rằng NAnt cũng có thể làm điều tương tự dựa trên blog này , được liên kết từ trang Ivy).

Ngoài ra còn có Byldan , một phiên bản .Net của Maven. Tuy nhiên, không biết điều đó sẽ hiệu quả với bạn như thế nào.

Make và GCC là một sự kết hợp tuyệt vời để kiểm tra độ phụ thuộc thực sự tốt.

GCC có thể tự động tạo các tệp phụ thuộc 'tạo' (chuyển đổi dòng lệnh -MD), để có thể xây dựng lại tất cả các tệp nguồn phụ thuộc vào một tiêu đề nhất định, chẳng hạn.

Tôi có một số quy tắc đơn giản mà tôi cắt-n-dán vào trang điểm của mình:

# compile c files   
%.o:    %.c
    ${CC} ${CFLAGS} -c $< -MD -MF $(<:%.c=%.dep) -o $@

# compile c++ files
%.opp:  %.cpp
    ${CPP} ${CPPFLAGS} -c $< -MD -MF $(<:%.cpp=%.dep) -o $@

Bây giờ nếu các tệp đối tượng của bạn được khai báo trong danh sách OBJ_C và OBJ_CPP:

.PHONY: cleandep
cleandep:
    rm -f $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)

-include $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)

Tất nhiên, Make có thể theo dõi sự phụ thuộc với các dự án khác và như vậy, chẳng hạn như xây dựng lại một thư viện dùng chung nếu cần.

Ví dụ: nếu các nhóm khác của bạn luôn đặt các tệp DLL mới nhất của họ trên một số thư mục chia sẻ:

myapp: ${SRC_CPP} ${LIB_DIR}other_team.lib
  ...

${LIB_DIR}other_team.lib: /shared_folder/latest/other_team.lib
  cp /shared_folder/latest/other_team.lib ${LIB_DIR}other_team.lib

Biên tập:

Mã sinh học không được dùng nữa

Thay thế: Conan.io

Tôi giới thiệu conan , mà tôi đã sử dụng những ngày này. Nó rất mạnh mẽ để duy trì tất cả các thư viện và mã nhị phân phụ thuộc trong dự án của bạn.

Bạn có thể tạo gói NuGet cho các thư viện đã sử dụng và sử dụng NuGet để quản lý phụ thuộc.

Xem thêm, NuGet cho C ++

Có một số công cụ nằm trên SCons, cung cấp chức năng cấp cao hơn tương tự như công cụ của Autotools đang cố gắng làm cho cuộc sống của các nhà phát triển dễ dàng hơn (ví dụ: WAF, SNOCS). Thật không may, bản thân SCons có nhược điểm lớn - thời gian biên dịch lâu hơn cho các dự án lớn.

Tôi có thể khuyên bạn nên dùng thử SNOCS (là một SCons bị đảo ngược) cho những người bạn đang tìm kiếm một quản lý phụ thuộc dễ dàng và chọn các tùy chọn biên dịch trong một lệnh (trình biên dịch, x86 / x64, Gỡ lỗi / Phát hành, thư viện tĩnh / chia sẻ, thử nghiệm / cài đặt mục tiêu, v.v.).

SNOCS cũng cố gắng giải quyết vấn đề thời gian biên dịch dài bằng cách lưu trữ đầu ra cấu hình dự án trong các tệp riêng biệt, cho phép các bản dựng do đó hoàn toàn bỏ qua giai đoạn cấu hình và chuyển thẳng đến giai đoạn xây dựng (tính năng cuối cùng hiện đang được xây dựng)

Cấu hình của CMake trở nên tẻ nhạt trong các giải pháp lớn hơn, do đó, việc bảo trì hệ thống xây dựng chiếm một phần lớn thời gian của nhà phát triển. May mắn thay như Martijn đã đề cập đến có mã sinh học "sử dụng CMake để tạo dự án của bạn với các phụ thuộc của nó".

Thử SCons

SCons là một công cụ xây dựng phần mềm Nguồn mở — nghĩa là, một công cụ xây dựng thế hệ tiếp theo. Hãy nghĩ về SCons như một sự thay thế đa nền tảng, được cải tiến cho tiện ích Make cổ điển với chức năng tích hợp tương tự như autoconf / automake và bộ đệm biên dịch như ccache. Tóm lại, SCons là một cách dễ dàng hơn, đáng tin cậy hơn và nhanh hơn để xây dựng phần mềm.

Tôi khuyên bạn nên sử dụng mẹ của tất cả các hệ thống phụ thuộc xây dựng: make.

Hãy thử scons, bạn sẽ bị mắc câu. Make đã lỗi thời, khó bảo trì và tốn kém.