2009-12-18 45 views
41

Một vài năm trước, tôi đã xem xét sử dụng một số hệ thống xây dựng không phải là Make và các công cụ như CMake và SCons có vẻ khá nguyên thủy. Tôi muốn tìm hiểu xem tình hình đã được cải thiện chưa. Vì vậy, theo các tiêu chí sau, những gì hiện đang xây dựng công cụ tốt nhất:Hiện tại hệ thống xây dựng tốt nhất là gì

  • dựa vào nền tảng: nên làm việc trên cửa sổ, linux, mac
  • ngôn ngữ thuyết bất khả tri: nên có built-in hỗ trợ cho những thứ phổ biến như xây dựng C/C++ và các ngôn ngữ tĩnh khác. Tôi đoán nó không cần phải hỗ trợ toàn bộ bộ tự động.
  • có thể mở rộng: Tôi cần có thể viết quy tắc để tạo tệp, như từ cấu trúc lại, mủ, định dạng tùy chỉnh, v.v. Tôi không thực sự quan tâm ngôn ngữ nào tôi phải viết quy tắc, nhưng tôi thích ngôn ngữ thực hơn hơn DSL.
  • Tôi muốn tránh viết bất kỳ XML nào bằng tay, mà tôi nghĩ ví dụ: ant yêu cầu.
  • Tự do có sẵn (nguồn tốt nhất là mở)

Thuật ngữ "tốt nhất" là hơi chủ quan, nhưng tôi nghĩ rằng câu trả lời có thể được đánh giá một cách khách quan bởi các tiêu chí trên.

+0

Tôi đang bối rối. Bạn nói "nó không cần phải hỗ trợ toàn bộ autotools suite". Điều này có nghĩa là câu hỏi của bạn nên được lặp lại: "Hệ thống xây dựng tốt nhất tiếp theo sau khi autoconf/automake là gì?" –

+0

@William Pursell: Không. Tôi rõ ràng đã loại bỏ yêu cầu hỗ trợ autoconf và automake, vì nó được kết hợp chặt chẽ với Makefiles. –

+1

Tôi không thấy bất kỳ điều gì sai với câu hỏi gốc hoặc thảo luận kết quả. Cho rằng câu hỏi này bây giờ là công cụ tìm kiếm dẫn đầu cho "hệ thống xây dựng tốt nhất", câu hỏi này nên được mở cửa trở lại. Tôi có thể hiểu việc đóng nó nếu cuộc thảo luận trên thực tế đã được đưa ra ý kiến, hoặc nếu nó thực sự đã thu hút spam, nhưng điều đó không đúng. – user1110743

Trả lời

23

Tôi chắc chắn sẽ bỏ phiếu cho số premake. Mặc dù nó không phải là mạnh mẽ như anh em lớn tuổi của nó, đó là lợi thế chính là vô lý đơn giản và dễ sử dụng. Làm cho việc viết nhiều trình biên dịch, mã đa nền tảng trở nên dễ dàng, và tự nhiên tạo ra các giải pháp Visual Studio, các dự án XCode, Makefiles và các phần mềm khác mà không cần bất kỳ công việc bổ sung nào.

+0

Trông rất đẹp. Điều đó nói rằng, nó không giống như nó hỗ trợ nhiều "ra khỏi hộp"? –

+2

Và Premake nhúng một thông dịch viên Lua, một ngôn ngữ kịch bản mạnh mẽ hơn ngôn ngữ của CMake, theo ý kiến ​​của tôi. – Splo

+1

Và không cần tải xuống trình thông dịch Python cho Windows như Scons hoặc Waf. – Splo

-1

Final Builder nổi tiếng trong Windows thế giới

+3

Tôi đã không nghĩ đến đề cập rằng nó nên được miễn phí (tốt nhất là trong bài phát biểu). Tôi đã cố định câu hỏi. –

+0

Wow. Mặc dù nó trông giống như một chương trình chỉ tải xuống, họ sử dụng các biểu tượng nhắc nhở tôi về hộp Vista không thể tìm ra được. – Ken

0

Dự án Selenium được chuyển giao cho Rake, không phải vì hết sức mình nhưng vì nó xử lý nhiều ngôn ngữ tốt hơn một chút so với tất cả các công cụ xây dựng khác và là nền tảng chéo (được phát triển trong Ruby).

Tất cả công cụ xây dựng đều có vấn đề và mọi người học cách sống chung với họ. Cái gì mà chạy trên JVM có xu hướng được thực sự tốt cho việc xây dựng các ứng dụng để Ant, Maven (i biết gớm ghiếc của nó), Ivy, Rake

6

CMake

CMake là một mở rộng, mã nguồn mở hệ thống quản lý quá trình xây dựng trong hệ điều hành và theo cách độc lập của trình biên dịch .

+0

Tôi thu thập nó đã có vấn đề cửa sổ một vài năm trước đây. Họ có cố định không? –

+0

Tôi chỉ mới bắt đầu sử dụng nó gần đây và tôi chưa gặp sự cố. Xem xét rằng MySQL sử dụng nó cho Windows của nó xây dựng, tôi không thể nhìn thấy nó có vấn đề lớn. –

+2

CMake tốt hơn nhiều so với autotools nhưng nó vẫn sử dụng DSL của riêng mình và tôi thấy đây là một trở ngại: Bạn phải đầu tư vào việc học ngôn ngữ mới. Vì lý do này tôi sẽ đi cho các giải pháp như Waf (Python) hoặc Rake (Ruby). – sorin

13

Vì vậy, xét hoàn toàn theo các tiêu chí được đặt ra trong câu hỏi, hệ thống xây dựng có vẻ phù hợp nhất có lẽ là waf - Python tinh khiết, cung cấp hỗ trợ cho C++ và các ngôn ngữ khác, nói chung, mạnh mẽ, không phải DSL.


Tuy nhiên, từ kinh nghiệm cá nhân của tôi, tôi thích CMake cho dự án C++ hơn. (Tôi đã thử CMake, SCons, và waf, và thích chúng theo thứ tự đó). CMake là một giải pháp chung, nhưng nó có hỗ trợ tích hợp cho C++ khiến nó trở nên đẹp hơn một giải pháp chung chung hơn khi bạn đang thực sự làm C++.

Mô hình xây dựng của CMake cho C++ là khai báo nhiều hơn và ít bắt buộc hơn, và do đó, với tôi, dễ sử dụng hơn.Cú pháp ngôn ngữ CMake không phải là tuyệt vời, nhưng việc xây dựng khai báo với cú pháp lẻ đánh bại một bản dựng bắt buộc bằng Python. Trong số ba, CMake cũng có vẻ có sự hỗ trợ tốt nhất cho những thứ "tiên tiến" như các tiêu đề được biên dịch trước. Việc thiết lập các tiêu đề được biên dịch trước đã giảm thời gian xây dựng lại của tôi xuống khoảng 70%.

Điểm cộng khác cho CMake bao gồm tài liệu phong phú và cộng đồng khá lớn. Nhiều thư viện nguồn mở có CMake xây dựng các tệp hoặc trong cây hoặc do cộng đồng CMake cung cấp. Có những dự án lớn đã sử dụng CMake (OGRE đến với tâm trí), và các dự án lớn khác, như Boost và LLVM, đang trong quá trình chuyển sang CMake.

Một phần vấn đề tôi tìm thấy khi thử nghiệm với hệ thống xây dựng là tôi đang cố gắng xây dựng plugin NPAPI trên OS X và hóa ra rất ít hệ thống xây dựng được thiết lập để cung cấp cho XCode sự kết hợp chính xác của cờ bắt buộc làm như vậy. CMake, nhận ra rằng XCode là một mục tiêu phức tạp và di chuyển, cung cấp một móc để tự thiết lập các lệnh trong các dự án XCode được tạo ra (và Visual Studio, tôi nghĩ). Điều này là rất thông minh như xa như tôi đang quan tâm.

Cho dù bạn đang xây dựng thư viện hay ứng dụng cũng có thể xác định hệ thống xây dựng nào là tốt nhất. Boost vẫn sử dụng hệ thống dựa trên mứt, một phần vì nó cung cấp sự hỗ trợ toàn diện nhất để quản lý các loại xây dựng phức tạp hơn "Gỡ lỗi" và "Phát hành". Hầu hết các thư viện tăng có năm hoặc sáu phiên bản khác nhau, đặc biệt là trên Windows, dự đoán mọi người cần các thư viện tương thích liên kết với các phiên bản CRT khác nhau.

Tôi không gặp bất kỳ sự cố nào với CMake trên Windows, nhưng tất nhiên số dặm của bạn có thể thay đổi. Có một GUI phong nha để thiết lập các phụ thuộc xây dựng, mặc dù nó là clunky để sử dụng cho việc xây dựng lại. May mắn thay, đó cũng là một khách hàng dòng lệnh. Những gì tôi đã giải quyết cho đến nay là có một Makefile bao bọc mỏng để gọi CMake từ một objdir; Sau đó, CMake tạo Makefiles trong objdir và Makefile ban đầu sử dụng chúng để thực hiện việc xây dựng. Điều này đảm bảo rằng mọi người không vô tình gọi CMake từ thư mục nguồn và làm lộn xộn kho lưu trữ của họ. Kết hợp với MinGW, "bánh sandwich CMake" này cung cấp trải nghiệm xây dựng đa nền tảng nhất quán đáng kể!

+0

Tôi phải đứng thứ hai. MacOSX và CMake không chỉ là một giải pháp nếu bạn có chất lượng trong tâm trí (sử dụng các công cụ như hỗ trợ quốc tế hóa). Tôi sẽ di chuyển hệ thống xây dựng của chúng tôi một ngày, nó hiện đang hoạt động được chấp nhận cho một ứng dụng chỉ có tiếng Anh đơn giản – Lothar

+0

WAF là mã chất lượng thấp không đáng kể. Không thể mở rộng hoặc thậm chí để đọc (tôi đã tự hỏi nếu nó đã được obfuscated về mục đích, nhưng bất cứ điều gì nó, dường như là phiên bản duy nhất có). Không thể gỡ lỗi hoặc dự đoán nó sẽ làm gì. Đó là một trò đùa của một chương trình phần mềm thiết kế wrt, mã hóa Python hoàn toàn lame trộn lẫn với việc tạo mã thời gian chạy kỳ cục, nơi nó hoàn toàn không cần thiết. Aaaand ... nó có một cuốn sách viết về nó * facepalm *. – wvxvw

12

Tất nhiên điều đó tùy thuộc vào mức độ ưu tiên của bạn. Nếu bạn đang tìm kiếm chủ yếu để dễ sử dụng, có ít nhất hai hệ thống xây dựng mới móc vào hệ thống tệp để tự động theo dõi các phụ thuộc theo kiểu thời trang bất khả tri về ngôn ngữ.

Một là TUP:

http://gittup.org/tup/

và thứ hai là chế tạo:

http://code.google.com/p/fabricate/

Một trong đó có vẻ là thực hiện tốt nhất, di động, và trưởng thành (và một trong những Tôi đã thực sự sử dụng) là tup. Người đã viết nó thậm chí còn duy trì một bản phân phối Linux đồ chơi, nơi mọi thứ đều là một mô-đun con git, và mọi thứ (bao gồm cả hạt nhân) được xây dựng với tup. Từ những gì tôi đã đọc về hệ thống xây dựng của hạt nhân, đây hoàn toàn là một thành tựu.

Ngoài ra, Tup dọn sạch các mục tiêu cũ và các hành trình khác, và có thể tự động duy trì các tệp .gitignore của bạn. Kết quả là nó trở nên tầm thường để thử nghiệm với cách bố trí và tên của các mục tiêu của bạn, và bạn có thể tự tin nhảy giữa các phiên bản git mà không cần xây dựng lại mọi thứ. Nó được viết bằng C.

Nếu bạn biết Haskell và đang tìm kiếm một cái gì đó đối với trường hợp sử dụng rất tiên tiến, kiểm tra rung:

http://community.haskell.org/~ndm/shake/

Cập nhật: Tôi đã không thử nó, nhưng mới "buildsome" công cụ này cũng móc vào hệ thống tập tin, và được lấy cảm hứng từ trừu đực, như vậy là có liên quan:

https://github.com/ElastiLotem/buildsome

+0

Sự hiểu biết của tôi là làm lại không móc vào hệ thống tập tin ở tất cả, chỉ tup và chế tạo làm. –

2

Gradle dường như để phù hợp với tất cả các tiêu chí nêu trên.

Đó là một hệ thống xây dựng có kết hợp tốt nhất của Maven và Ant. Với tôi, đó là điều tốt nhất.

-2

smooth build khớp với hầu hết các yêu cầu của bạn.

  • dựa vào nền tảng: yes, nó được viết bằng java
  • ngôn ngữ thuyết bất khả tri: nó không hỗ trợ c/C++ t nào, chỉ java nhưng nó là có thể mở rộng thông qua các plugin viết bằng java nên bổ sung thêm các trình biên dịch hỗ trợ không phải là vấn đề
  • có thể mở rộng: có, bạn có thể thực hiện chức năng mượt mà thông qua plugin java, bạn cũng có thể tạo chức năng mượt mà thông qua xác định nó dưới dạng biểu thức được tạo bởi các hàm mượt mà khác.
  • tôi muốn tránh bằng văn bản bất kỳ XML: bạn sẽ không thấy một dòng duy nhất của nó trong xây dựng mịn
  • Tự do có sẵn: yes, Apache 2 giấy phép

tiết lộ: Tôi là tác giả của mịn xây dựng.

Các vấn đề liên quan