Có phải automake và autoconf là cách chuẩn để biên dịch mã?

Đôi khi tôi biên dịch các ứng dụng từ nguồn và tôi đã và đang sử dụng:

./configure
make
sudo make install

Nhưng gần đây, tôi đã tình cờ ./autogen.shtạo ra cấu hình và tạo tập lệnh cho tôi và thực thi chúng.

Những phương pháp khác để hợp lý hóa quá trình biên dịch C / C ++ / C # (mono) tồn tại? Làm có vẻ hơi cũ. Có những công cụ mới ngoài kia? Đưa ra lựa chọn, tôi nên sử dụng cái nào?

Autoconf và Automake đã được đặt ra để giải quyết vấn đề tiến hóa của Unix.

Khi Unix phát triển theo các hướng khác nhau, các nhà phát triển muốn mã di động có xu hướng viết mã như thế này:

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

Khi Unix được chia thành các triển khai khác nhau (BSD, SystemV, nhiều nhánh của nhà cung cấp và sau này là Linux và các hệ thống tương tự Unix khác), điều quan trọng đối với các nhà phát triển muốn viết mã di động để viết mã không phụ thuộc vào một thương hiệu cụ thể của hệ điều hành , nhưng trên các tính năng tiếp xúc với hệ điều hành. Điều này rất quan trọng vì một phiên bản Unix sẽ giới thiệu một tính năng mới, ví dụ như cuộc gọi hệ thống "gửi" và sau đó các hệ điều hành khác sẽ áp dụng nó. Thay vì có một spaghetti mã kiểm tra các nhãn hiệu và phiên bản, các nhà phát triển bắt đầu thăm dò bằng các tính năng, vì vậy mã đã trở thành:

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

Hầu hết các tệp README để biên dịch mã nguồn trong các nhà phát triển nhọn của thập niên 90 để chỉnh sửa tệp config.h và nhận xét rằng các tính năng phù hợp có sẵn trên hệ thống hoặc sẽ gửi các tệp config.h tiêu chuẩn cho từng cấu hình hệ điều hành đã được kiểm tra.

Quá trình này vừa cồng kềnh vừa dễ bị lỗi và đây là cách Autoconf ra đời. Bạn nên nghĩ về Autoconf như một ngôn ngữ được tạo thành từ các lệnh shell với các macro đặc biệt có thể thay thế quá trình chỉnh sửa con người của config.h bằng một công cụ thăm dò hệ điều hành cho chức năng.

Thông thường bạn sẽ viết mã thăm dò của mình trong tệp configure.ac và sau đó chạy lệnh autoconf sẽ biên dịch tệp này thành lệnh cấu hình thực thi mà bạn đã thấy được sử dụng.

Vì vậy, khi bạn chạy, ./configure && makebạn đã thăm dò các tính năng có sẵn trên hệ thống của mình và sau đó xây dựng chương trình thực thi với cấu hình được phát hiện.

Khi các dự án nguồn mở bắt đầu sử dụng các hệ thống kiểm soát mã nguồn, việc kiểm tra tệp configure.ac, nhưng không phải là kết quả của quá trình biên dịch (configure). Autogen.sh chỉ là một tập lệnh nhỏ gọi trình biên dịch autoconf với các đối số lệnh đúng cho bạn.

-

Automake cũng phát triển từ các hoạt động hiện có trong cộng đồng. Dự án GNU đã chuẩn hóa một bộ mục tiêu thông thường cho Makefiles:

• make all sẽ xây dựng dự án
• make clean sẽ xóa tất cả các tệp đã biên dịch khỏi dự án
• make install sẽ cài đặt phần mềm
• những thứ như make distvà make distchecksẽ chuẩn bị nguồn để phân phối và xác minh rằng kết quả là một gói mã nguồn hoàn chỉnh
• và v.v.

Xây dựng các makefile tuân thủ trở nên nặng nề bởi vì có rất nhiều nồi hơi được lặp đi lặp lại nhiều lần. Vì vậy, Automake là một trình biên dịch mới được tích hợp với autoconf và đã xử lý "nguồn" Makefile's (tên là Makefile.am) thành Makefiles mà sau đó có thể được cung cấp cho Autoconf.

Chuỗi công cụ automake / autoconf thực sự sử dụng một số công cụ trợ giúp khác và chúng được tăng cường bởi các thành phần khác cho các tác vụ cụ thể khác. Khi sự phức tạp của việc chạy các lệnh này theo thứ tự tăng lên, nhu cầu về một kịch bản sẵn sàng để chạy đã được sinh ra, và đây là nơi autogen.sh xuất phát.

Theo như tôi biết, Gnome là dự án giới thiệu việc sử dụng tập lệnh trợ giúp autogen.sh này

Có hai "Người chơi lớn" trong lĩnh vực này; Cmake và GNU Autotools.

• GNU Autotools là cách GNU để thực hiện mọi việc và khá tập trung vào * nix. Đây là một loại hệ thống xây dựng meta, cung cấp một bộ công cụ tạo cấu hình cụ thể và tạo các tệp cho những gì bạn đang cố gắng thực hiện. Điều này giúp bạn thực hiện nhiều thay đổi hơn trong mã của mình mà không phải thao tác trực tiếp với hệ thống xây dựng của mình và nó giúp người khác xây dựng mã của bạn theo cách bạn đã thiết kế cho - dưới * nix.

• Cmake là cách đa nền tảng để làm mọi việc. Nhóm Cmake xây dựng phần mềm trên nhiều cách khác nhau, với GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux, bất cứ điều gì. Nếu bạn hoàn toàn lo ngại về tính di động của cơ sở mã của mình, đây là cách để đi.

Như đã đề cập, một số người có vẻ thích Scons. Nếu bạn quen thuộc với Python, điều này có thể cung cấp sự nhất quán hơn trong môi trường làm việc của bạn.

Ruby cũng có một loại hệ thống xây dựng meta gọi là Rake, khá tuyệt vời theo đúng nghĩa của nó, và rất tiện dụng cho những người đã quen thuộc với Ruby.

Scons là một trong những thay thế có thể, mặc dù tôi không có kinh nghiệm cá nhân. Nó cũng được triển khai trong Python, có thể là một vấn đề, tùy thuộc vào môi trường xây dựng.

Nếu bạn đang sử dụng C # / Mono, bạn có thể sử dụng msbuild (các tệp .sln / .csproj được sử dụng bởi MonoDevelop và Visual Studio) để quản lý toàn bộ quá trình xây dựng của bạn.

Sau đó, bạn có thể xây dựng từ MonoDevelop hoặc chạy xbuildlệnh trong thiết bị đầu cuối yêu thích của bạn (hoạt động tốt nhất trong Mono> = 2.6). Điều này cực kỳ dễ dàng và không đòi hỏi nhiều công sức của bạn, vì MonoDevelop sẽ xử lý các tệp msbuild cho bạn và bạn sẽ không cần chỉnh sửa chúng trừ khi bạn muốn điều chỉnh những thứ vượt quá những gì UI của MonoDevelop có thể làm cho bạn.

Tôi không quen với cách những người phụ thuộc vào msbuild xử lý các bản cài đặt cho các dự án của họ, nhưng bạn luôn có thể hỏi điều đó. ;-)

Đối với C #, bạn có thể sử dụng xbuild (và msbuild trên windows), sẽ xây dựng dự án từ các tệp dự án của bạn.