SCons hoặc CMake thay vì qmake

Question

Tôi cần một số lời khuyên trong các vấn đề sau:

Tôi có một dự án QT, hiện được thiết lập để hoạt động tốt với qmake. Tuy nhiên, do mở rộng các yêu cầu và hướng tương lai của dự án, tôi cần phải thay đổi hệ thống xây dựng của nó, vì ứng dụng sẽ yêu cầu một số thay đổi theo cách nó sẽ được xây dựng.

Ngay bây giờ mọi tệp nguồn được biên dịch thành tệp thực thi khá lớn, tệp này được đóng gói (theo cách thủ công) và được gửi đến khu vực tải xuống. Tất cả đều ổn.

Nhưng hướng tôi đang hướng đến là mô đun hóa ứng dụng theo cách mà mỗi "tính năng" sẽ được biên dịch thành một thư viện được chia sẻ và người dùng (nhà phát triển) sẽ có thể chọn các thành phần mà anh ta muốn biên dịch. Những "tính năng" này được đặt trong các thư mục trong cây nguồn (ví dụ: query_builder, thư mục reverse_engineer, mysql_DB_support, version_managemen, vv ...) và khi người dùng xây dựng ứng dụng, anh ta chỉ đơn giản nói với hệ thống xây dựng để biên dịch một ứng dụng với trình tạo truy vấn , và mysql, nhưng không có kỹ sư đảo ngược và trong trường hợp này, hệ thống xây dựng thêm các tệp nguồn từ thư mục được chỉ định và tạo một thư mục lib từ nó.

Tôi cũng có những yêu cầu khác như:

• cửa sổ xây dựng, linux xây dựng
• tùy chọn gói build (deb, rpm)
• hỗ trợ cho QT và có thể QT5
• nhiều thực thi (GUI khách hàng, khách hàng CLI)

Sau khi một số "nghiên cứu thị trường" tôi đã kết thúc với CMake và SCons dưới dạng hai chương trình có thể thân tôi có thể sử dụng. Tôi có một số kinh nghiệm CMake, và một số kinh nghiệm python, nhưng không có SCons nào được nêu ra.

Nhưng tôi không biết cái nào tốt nhất cho trường hợp của tôi, đây là nơi tôi cần sự giúp đỡ của bạn. Bạn có thể xây dựng mà tôi nên sử dụng? Và nếu bạn xem xét rằng các yêu cầu của tôi có thể đạt được với qmake, vui lòng cho tôi biết điều đó,

Chúc mừng, f.

Answer 1

Không có câu trả lời đúng cho câu hỏi này, và nó thường nắm để sở thích cá nhân, loại-giống như vi so với emacs (câu trả lời đúng là vi, tất nhiên :)

Bạn nên nghiên cứu những ưu và khuyết điểm của mỗi và đánh giá mức độ phù hợp với yêu cầu và nhu cầu của bạn.

Tôi là một phần của SCons, chủ yếu là vì tôi không thể chịu được cú pháp CMake, nhưng đó là sở thích cá nhân.Dưới đây là một số ưu và nhược điểm của mỗi khi tôi nhìn thấy nó:

CMake

Ưu điểm:

• Tương tự như qmake, coi đó là một máy phát điện makefile
• CMake được sử dụng rộng rãi, do đó, có rất nhiều tài liệu tham khảo và giúp sẵn có
• Có GUI (Tôi không biết chính bản thân mình , Dựa trên Calvin1602 ý kiến ​​dưới đây)

Nhược điểm:

• CMake có riêng của mình, phát minh ra cú pháp, mà nhiều người cảm giác (trong đó có tôi) không phải là trực quan.
• 2 bước xây dựng quy trình, đầu tiên tạo ra Makefiles, sau đó thực sự thực hiện việc biên soạn
• của nó gần như không thể đọc Makefiles tạo

SCons

Ưu điểm:

• Cú pháp là P ython, được sử dụng rộng rãi và tương đối dễ học. (và Python là mát mẻ :)
• Quá trình xây dựng là một bước, chỉ cần thực thi SCons và nó biên dịch. Không có tệp xây dựng trung gian nào để tạo hoặc duy trì.
• Trong quá khứ SCons chậm hơn so với CMake, nhưng kể từ đó nó nhanh hơn nhiều, có thể nhanh hoặc nhanh hơn CMake vì nó không phải tạo ra makefiles.
• Bộ tính năng phong phú và nhiều ngôn ngữ được hỗ trợ, trong khi CMake tập trung vào C/C++
• Hệ thống phụ thuộc hoàn toàn chính xác: không cần liệt kê rõ ràng tiêu đề phụ, thư viện, v.v.
• Plugin nhật thực có sẵn. Eclipse cũng có các plugin có sẵn cho Python.
• Có các công cụ được tạo cho các dự án Qt để xử lý MOC và các codegen có liên quan khác như được đề cập here.

Nhược điểm:

• SCons có thể không được sử dụng rộng rãi như CMake, nhưng vẫn có rất nhiều hỗ trợ sẵn.
• Tùy thuộc vào quy mô của dự án, SCons có thể sử dụng nhiều bộ nhớ, vì nó phân tích tất cả các kịch bản xây dựng và xây dựng cây phụ thuộc trong bộ nhớ trước khi biên dịch bất kỳ thứ gì. Tuy nhiên, điều này cho phép kiểm tra sự phụ thuộc chính xác hơn.