Mengapa selalu ./configure; membuat; membuat instal; sebagai 3 langkah terpisah?

Setiap kali Anda mengumpulkan sesuatu dari sumber, Anda melalui 3 langkah yang sama:

$ ./configure
$ make
$ make install

Saya mengerti, masuk akal untuk membagi proses penginstalan ke dalam langkah-langkah yang berbeda, tetapi saya tidak mengerti, mengapa setiap pembuat kode di planet ini harus menulis tiga perintah yang sama berulang kali hanya untuk menyelesaikan satu pekerjaan. Dari sudut pandang saya, akan sangat masuk akal jika ./install.shskrip dikirimkan secara otomatis dengan kode sumber yang berisi teks berikut:

#!/bin/sh
./configure
make
make install

mengapa orang melakukan 3 langkah secara terpisah?

Karena setiap langkah melakukan hal yang berbeda

Siapkan lingkungan (pengaturan) untuk membangun

./configure

Skrip ini memiliki banyak opsi yang harus Anda ubah. Suka --prefixatau --with-dir=/foo. Artinya setiap sistem memiliki konfigurasi yang berbeda. Juga ./configurememeriksa pustaka yang hilang yang harus diinstal. Ada yang salah di sini yang menyebabkan tidak membangun aplikasi Anda . Itulah mengapa distro memiliki paket yang diinstal di tempat yang berbeda, karena setiap distro berpikir lebih baik menginstal pustaka dan file tertentu ke direktori tertentu. Dikatakan berjalan ./configure, tetapi sebenarnya Anda harus selalu mengubahnya.

Misalnya, lihat situs paket Arch Linux . Di sini Anda akan melihat bahwa setiap paket menggunakan parameter konfigurasi yang berbeda (asumsikan mereka menggunakan autotools untuk sistem build).

Membangun sistem

make

Ini sebenarnya make allsecara default. Dan setiap merek memiliki tindakan yang berbeda untuk dilakukan. Beberapa membangun, beberapa melakukan tes setelah membangun, beberapa melakukan checkout dari repositori SCM eksternal. Biasanya Anda tidak perlu memberikan parameter apa pun, tetapi beberapa paket menjalankannya secara berbeda.

Instal ke sistem

make install

Ini menginstal paket di tempat yang ditentukan dengan konfigurasi. Jika mau, Anda dapat menentukan ./configureuntuk menunjuk ke direktori home Anda. Namun, banyak opsi konfigurasi yang mengarah ke /usratau /usr/local. Itu berarti Anda harus menggunakan sebenarnya sudo make installkarena hanya root yang dapat menyalin file ke / usr dan / usr / local.

Sekarang Anda melihat bahwa setiap langkah merupakan prasyarat untuk langkah berikutnya. Setiap langkah adalah persiapan untuk membuat segala sesuatunya berjalan lancar. Distro menggunakan metafora ini untuk membangun paket (seperti RPM, deb, dll.).

Di sini Anda akan melihat bahwa setiap langkah sebenarnya adalah keadaan yang berbeda. Itulah mengapa manajer paket memiliki pembungkus yang berbeda. Di bawah ini adalah contoh pembungkus yang memungkinkan Anda membangun seluruh paket dalam satu langkah. Namun perlu diingat bahwa setiap aplikasi memiliki pembungkus yang berbeda (sebenarnya pembungkus ini memiliki nama seperti spek, PKGBUILD, dll.):

def setup:
... #use ./configure if autotools is used

def build:
... #use make if autotools is used

def install:
... #use make all if autotools is used

Di sini seseorang dapat menggunakan autotools, itu artinya ./configure, makedan make install. Tetapi yang lain dapat menggunakan SCons, pengaturan terkait Python atau sesuatu yang berbeda.

Seperti yang Anda lihat, memisahkan setiap status membuat pemeliharaan dan penerapan menjadi lebih mudah, terutama untuk pengelola paket dan distro.

Pertama, harus ./configure && make && make installkarena masing-masing tergantung pada keberhasilan yang pertama. Sebagian alasannya adalah evolusi dan sebagian alasannya adalah kenyamanan untuk alur kerja pengembangan.

Awalnya, kebanyakan Makefiles hanya akan berisi perintah untuk mengkompilasi program dan instalasi diserahkan kepada pengguna. Aturan tambahan memungkinkan make installuntuk menempatkan output yang dikompilasi di tempat yang mungkin benar; masih banyak alasan bagus mengapa Anda mungkin tidak ingin melakukan ini, termasuk tidak menjadi administrator sistem, tidak ingin menginstalnya sama sekali. Selain itu, jika saya mengembangkan perangkat lunak, saya mungkin tidak ingin menginstalnya. Saya ingin membuat beberapa perubahan dan menguji versi yang ada di direktori saya. Ini menjadi lebih menonjol jika saya akan memiliki banyak versi.

./configurepergi dan mendeteksi apa yang tersedia di lingkungan dan / atau yang diinginkan oleh pengguna untuk menentukan bagaimana membangun perangkat lunak. Ini bukanlah sesuatu yang perlu sering diubah dan seringkali membutuhkan waktu. Sekali lagi, jika saya seorang pengembang, tidak sepadan dengan waktu untuk mengonfigurasi ulang secara konstan. Lebih penting lagi, karena makemenggunakan stempel waktu untuk membangun kembali modul, jika saya menjalankan kembali configureada kemungkinan bahwa tanda akan berubah dan sekarang beberapa komponen dalam build saya akan dikompilasi dengan satu set tanda dan lainnya dengan set tanda berbeda yang mungkin mengarah ke berbeda, perilaku tidak kompatibel. Selama saya tidak menjalankan ulang configure, saya tahu bahwa lingkungan kompilasi saya tetap sama meskipun saya mengubah sumber saya. Jika saya memutar ulang configure, saya harus melakukannyamake clean pertama, untuk menghapus semua sumber yang dibangun untuk memastikan segala sesuatunya dibangun secara seragam.

Satu-satunya kasus di mana tiga perintah dijalankan secara berurutan adalah ketika pengguna menginstal program atau paket dibuat (misalnya, debuild Debian atau rpmbuild RedHat). Dan itu mengasumsikan bahwa paket dapat diberikan polos configure, yang biasanya tidak terjadi pada kemasan, di mana, setidaknya, --prefix=/usrdiinginkan. Dan pacakgers seperti harus berurusan dengan akar palsu saat melakukan make installbagian itu. Karena ada banyak pengecualian, membuat ./configure && make && make installaturan akan merepotkan bagi banyak orang yang lebih sering melakukannya!

Pertama ./configure tidak selalu menemukan semua yang dibutuhkannya, atau dalam kasus lain ia menemukan semua yang dibutuhkannya tetapi tidak semua yang bisa digunakannya. Dalam hal ini, Anda ingin mengetahuinya (dan skrip ./install.sh Anda akan tetap gagal!) Contoh klasik non-kegagalan dengan konsekuensi yang tidak diinginkan, dari sudut pandang saya, adalah mengompilasi aplikasi besar seperti ffmpeg atau mplayer. Ini akan menggunakan pustaka jika tersedia tetapi akan tetap dikompilasi jika tidak, membiarkan beberapa opsi dinonaktifkan. Masalahnya adalah Anda kemudian menemukan kemudian bahwa itu dikompilasi tanpa dukungan untuk beberapa format atau lainnya, sehingga mengharuskan Anda untuk kembali dan mengulanginya.

Hal lain yang dilakukan ./configure agak interaktif adalah memberi Anda opsi untuk menyesuaikan di mana pada sistem aplikasi akan dipasang. Distribusi / lingkungan yang berbeda memiliki konvensi yang berbeda, dan Anda mungkin ingin tetap berpegang pada konvensi di sistem Anda. Selain itu, Anda mungkin ingin menginstalnya secara lokal (hanya untuk Anda sendiri). Secara tradisional, ./configure dan make steps tidak dijalankan sebagai root, sedangkan make install (kecuali jika diinstal hanya untuk Anda sendiri) harus dijalankan sebagai root.

Distribusi spesifik sering menyediakan skrip yang menjalankan fungsionalitas ./install.sh ini dengan cara yang peka terhadap distribusi - misalnya, file sumber RPM + spesifikasi + rpmbuild atau slackbuilds .

(Catatan kaki: seperti yang dikatakan, saya setuju bahwa ./configure; make; make install; bisa sangat membosankan.)

configure mungkin gagal jika menemukan bahwa dependensi hilang.

makemenjalankan target default, yang pertama terdaftar di Makefile. Seringkali target ini adalah all, tetapi tidak selalu. Jadi Anda hanya bisa make all installjika Anda tahu itu targetnya.

Jadi ...

#!/bin/sh

if ./configure $*; then
  if make; then
    make install
  fi
fi

atau:

./configure $* && ./make && ./make install

Ini $*dimasukkan karena seseorang sering kali harus memberikan opsi configure.

Tetapi mengapa tidak membiarkan orang melakukannya sendiri? Apakah ini benar-benar kemenangan besar?