Apakah automake dan autoconf cara standar untuk mengkompilasi kode?

Terkadang saya mengkompilasi aplikasi dari sumber dan saya telah menggunakan:

./configure
make
sudo make install

Namun baru-baru ini, saya menemukan ./autogen.shyang menghasilkan konfigurasi dan membuat skrip untuk saya dan mengeksekusinya.

Apa metode lain untuk merampingkan kompilasi C / C ++ / C # (mono) yang ada? Membuatnya tampak agak tua. Apakah ada alat baru di luar sana? Diberi pilihan, mana yang harus saya gunakan?

Autoconf dan Automake dibuat untuk menyelesaikan masalah evolusi Unix.

Saat Unix berkembang ke arah yang berbeda, pengembang yang menginginkan kode portabel cenderung menulis kode seperti ini:

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

Karena Unix dipecah menjadi implementasi yang berbeda (BSD, SystemV, banyak fork vendor, dan kemudian Linux dan sistem mirip Unix lainnya) menjadi penting bagi pengembang yang ingin menulis kode portabel untuk menulis kode yang tidak bergantung pada merek sistem operasi tertentu , tetapi pada fitur yang diekspos oleh sistem operasi. Ini penting karena versi Unix akan memperkenalkan fitur baru, misalnya panggilan sistem "kirim", dan kemudian sistem operasi lain akan mengadopsinya. Alih-alih memiliki spageti kode yang memeriksa merek dan versi, pengembang mulai memeriksa fitur, sehingga kode menjadi:

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

Sebagian besar file README untuk mengkompilasi kode sumber kembali pada pengembang berujung tahun 90-an untuk mengedit file config.h dan berkomentar bahwa fitur yang tepat tersedia pada sistem, atau akan mengirimkan file config.h standar untuk setiap konfigurasi sistem operasi yang telah diuji.

Proses ini rumit dan rawan kesalahan dan inilah bagaimana Autoconf muncul. Anda harus menganggap Autoconf sebagai bahasa yang terdiri dari perintah shell dengan makro khusus yang dapat menggantikan proses pengeditan manusia dari config.h dengan alat yang menyelidiki sistem operasi untuk fungsionalitasnya.

Anda biasanya akan menulis kode probing Anda di file configure.ac dan kemudian jalankan perintah autoconf yang akan mengkompilasi file ini ke perintah configure yang dapat dieksekusi yang telah Anda lihat digunakan.

Jadi, ketika Anda menjalankan ./configure && makeAnda sedang mencari fitur yang tersedia di sistem Anda dan kemudian membangun executable dengan konfigurasi yang terdeteksi.

Ketika proyek open source mulai menggunakan sistem kontrol kode sumber, masuk akal untuk memeriksa file configure.ac, tetapi bukan hasil kompilasi (configure). Autogen.sh hanyalah skrip kecil yang memanggil kompiler autoconf dengan argumen perintah yang tepat untuk Anda.

-

Automake juga tumbuh dari praktik yang ada di komunitas. Proyek GNU menstandarisasi serangkaian target reguler untuk Makefiles:

• make all akan membangun proyek
• make clean akan menghapus semua file yang dikompilasi dari proyek
• make install akan menginstal perangkat lunak
• hal-hal seperti make distdan make distcheckakan menyiapkan sumber untuk distribusi dan memverifikasi bahwa hasilnya adalah paket kode sumber lengkap
• dan seterusnya...

Membangun makefile yang memenuhi persyaratan menjadi memberatkan karena ada banyak pelat ketel yang berulang-ulang. Jadi Automake adalah kompiler baru yang terintegrasi dengan autoconf dan memproses "source" Makefile's (bernama Makefile.am) menjadi Makefile yang kemudian dapat dimasukkan ke Autoconf.

Automchain / autoconf toolchain sebenarnya menggunakan sejumlah alat bantu lain dan mereka ditambah oleh komponen lain untuk tugas spesifik lainnya. Seiring dengan semakin rumitnya menjalankan perintah-perintah ini, kebutuhan untuk skrip siap-pakai lahir, dan dari sinilah autogen.sh berasal.

Sejauh yang saya tahu, Gnome adalah proyek yang memperkenalkan penggunaan skrip pembantu ini autogen.sh

Ada dua "pemain besar" di area ini; Cmake, dan GNU Autotools.

• GNU Autotools adalah cara GNU untuk melakukan sesuatu, dan cukup fokus pada * nix. Ini semacam sistem meta-build, menyediakan seperangkat alat yang menghasilkan konfigurasi khusus dan membuat file untuk apa yang Anda coba lakukan. Ini membantu Anda membuat lebih banyak perubahan pada kode Anda tanpa harus secara langsung memanipulasi sistem build Anda, dan membantu orang lain membangun kode Anda dengan cara yang tidak Anda rancang untuk - di bawah * nix.

• Cmake adalah cara lintas platform untuk melakukan sesuatu. Tim Cmake membangun perangkat lunak dengan berbagai cara, dengan GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux, apa pun. Jika Anda benar-benar peduli dengan portabilitas basis kode Anda, inilah cara yang harus dilakukan.

Seperti yang telah disebutkan, beberapa orang tampaknya menyukai Scons. Jika Anda terbiasa dengan Python, ini mungkin memberikan lebih banyak konsistensi dalam lingkungan kerja Anda.

Ruby juga memiliki semacam sistem meta-build yang disebut Rake, yang cukup keren, dan sangat berguna bagi mereka yang sudah terbiasa dengan Ruby.

Scons adalah salah satu pengganti yang mungkin, meskipun saya tidak punya pengalaman pribadi. Ini juga diimplementasikan dalam Python, yang bisa menjadi masalah, tergantung pada lingkungan build.

Jika Anda menggunakan C # / Mono, Anda dapat menggunakan msbuild (file .sln / .csproj yang digunakan oleh MonoDevelop dan Visual Studio) untuk mengelola seluruh proses build Anda.

Anda kemudian dapat membangun dari MonoDevelop, atau menjalankan xbuildperintah di terminal favorit Anda (berfungsi terbaik di Mono> = 2.6). Ini sangat mudah dan tidak memerlukan banyak pekerjaan dari Anda, karena MonoDevelop akan menangani file msbuild untuk Anda, dan Anda tidak perlu mengeditnya kecuali Anda ingin mengubah hal-hal di luar apa yang dapat dilakukan UI MonoDevelop untuk Anda.

Saya tidak terbiasa dengan bagaimana orang-orang yang bergantung pada msbuild menangani instalasi untuk proyek mereka, tetapi Anda selalu bisa menanyakan itu. ;-)

Untuk C # Anda dapat menggunakan xbuild (dan msbuild di windows), yang akan membangun proyek dari file proyek Anda.