Neden her zaman ./configure; Yapmak; kurmak yapmak; 3 ayrı adım olarak?

Kaynaktan bir şeyi her derlediğinizde, aynı 3 adımdan geçersiniz:

$ ./configure
$ make
$ make install

Kurulum sürecini farklı adımlara bölmenin mantıklı olduğunu anlıyorum, ama anlamıyorum, neden bu gezegendeki her bir kodlayıcının tek bir işi bitirmek için aynı üç komutu tekrar tekrar yazmak zorunda kalması. Benim bakış açıma göre ./install.sh, aşağıdaki metni içeren kaynak koduyla otomatik olarak teslim edilen bir betiğe sahip olmak tamamen mantıklı olacaktır :

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

İnsanlar neden 3 adımı ayrı ayrı yapsın?

Çünkü her adım farklı şeyler yapıyor

Bina için ortam hazırlayın (kurulum)

./configure

Bu komut dosyası, değiştirmeniz gereken birçok seçeneğe sahiptir. Gibi --prefixveya --with-dir=/foo. Bu, her sistemin farklı bir konfigürasyona sahip olduğu anlamına gelir. Ayrıca ./configureyüklenmesi gereken eksik kitaplıkları da denetler. Burada yanlış olan herhangi bir şey , uygulamanızı oluşturmamanıza neden olur . Bu nedenle dağıtımların farklı yerlere yüklenmiş paketleri vardır, çünkü her dağıtım belirli kitaplıkları ve dosyaları belirli dizinlere yüklemenin daha iyi olduğunu düşünür. Koşması söyleniyor ./configure, ama aslında onu her zaman değiştirmelisiniz.

Örneğin , Arch Linux paketleri sitesine bir göz atın . Burada herhangi bir paketin farklı bir configure parametresi kullandığını göreceksiniz (derleme sistemi için autotools kullandıklarını varsayın).

Sistemi kurmak

make

Bu aslında make allvarsayılan olarak. Ve her markanın yapacak farklı eylemleri vardır. Bazıları derleme yapar, bazıları oluşturduktan sonra testler yapar, bazıları ise harici SCM havuzlarından kullanıma alır. Genellikle herhangi bir parametre vermeniz gerekmez, ancak yine bazı paketler onları farklı şekilde çalıştırır.

Sisteme yükleyin

make install

Bu, paketi configure ile belirtilen yere yükler. İsterseniz ./configure, ana dizininize işaret etmeyi belirtebilirsiniz . Ancak, birçok yapılandırma seçeneği /usrveya işaretini gösteriyor /usr/local. Bu, o zaman gerçekten kullanmanız gerektiği anlamına gelir sudo make installçünkü yalnızca root dosyaları / usr ve / usr / local dizinlerine kopyalayabilir.

Artık her adımın bir sonraki adım için bir ön gereklilik olduğunu görüyorsunuz. Her adım, işlerin sorunsuz bir akış içinde yürümesi için bir hazırlıktır. Dağıtımcılar bu metaforu paketler (RPM, deb vb. Gibi) oluşturmak için kullanır.

Burada her adımın aslında farklı bir durum olduğunu göreceksiniz. Bu nedenle paket yöneticilerinin farklı sarmalayıcıları vardır. Aşağıda, tüm paketi tek adımda oluşturmanıza izin veren bir sarmalayıcı örneği bulunmaktadır. Ancak her uygulamanın farklı bir sarmalayıcıya sahip olduğunu unutmayın (aslında bu sarmalayıcıların spec, PKGBUILD, vb. Gibi bir adı vardır):

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

Burada bir tane, aracı autotools kullanabilir ./configure, makeve make install. Ancak bir diğeri SCons, Python ile ilgili kurulum veya farklı bir şey kullanabilir.

Gördüğünüz gibi her durumu bölmek, özellikle paket bakımcıları ve dağıtımlar için bakım ve dağıtım için işleri çok daha kolaylaştırır.

Birincisi, ./configure && make && make installher biri birincisinin başarısına bağlı olduğu için olmalıdır . Sebebin bir kısmı evrimdir ve bunun bir kısmı da geliştirme iş akışı için kolaylıktır.

Başlangıçta, çoğu Makefiles yalnızca bir programı derlemek için komutları içerirdi ve kurulum kullanıcıya bırakılırdı. Ekstra bir kural make install, derlenen çıktının doğru olabilecek bir yere yerleştirilmesine izin verir ; Sistem yöneticisi olmamak, hiç kurmak istememek dahil, bunu yapmak istemeyebilmeniz için hala birçok iyi neden var. Dahası, eğer yazılımı geliştiriyorsam, muhtemelen yüklemek istemiyorum. Bazı değişiklikler yapmak ve dizinimde bulunan sürümü test etmek istiyorum. Etrafta birden fazla versiyonum olacaksa, bu daha da belirgin hale geliyor.

./configureOrtamda neyin mevcut olduğunu ve / veya yazılımın nasıl oluşturulacağını belirlemek için kullanıcı tarafından arzu edildiğini gider ve algılar. Bu, çok sık değişmesi gereken bir şey değildir ve çoğu zaman biraz zaman alabilir. Yine, eğer bir geliştiriciysem, sürekli olarak yeniden yapılandırmaya zaman ayırmaya değmez. Daha da önemlisi, makemodülleri yeniden oluşturmak için zaman damgaları kullandığından, yeniden çalıştırırsam configurebayrakların değişme olasılığı vardır ve şimdi yapımdaki bazı bileşenlerin bir dizi bayrakla ve diğerlerinin de yol açabilecek farklı bir bayrak kümesiyle derlenmesi farklı, uyumsuz davranış. Yeniden çalıştırmadığım sürece, configurekaynaklarımı değiştirsem bile derleme ortamımın aynı kaldığını biliyorum. Yeniden yayınlarsam configure, yapmalıyımmake clean ilk olarak, nesnelerin tek tip olarak inşa edilmesini sağlamak için herhangi bir yerleşik kaynağı kaldırmak.

Üç komutun arka arkaya çalıştırıldığı tek durum, kullanıcıların programı kurması veya bir paketin oluşturulmasıdır (örn. Debian'ın debuild veya RedHat'ın rpmbuild'i). Ve bu, pakete düz bir şekilde verilebileceğini varsayar configure, ki bu genellikle paketleme için geçerli değildir, en azından --prefix=/usrarzu edilirse. Ve pacakgers, rolü yaparken sahte köklerle uğraşmak zorunda kalırlar make install. Pek çok istisna olduğu için ./configure && make && make install, kural koymak, bunu çok daha sık yapan pek çok insan için sakıncalı olacaktır!

İlk olarak ./configure her zaman ihtiyaç duyduğu her şeyi bulmaz veya diğer durumlarda ihtiyaç duyduğu her şeyi bulur ama kullanabileceği her şeyi bulamaz. Bu durumda, onu bilmek istersiniz (ve ./install.sh betiğiniz yine de başarısız olur!) Benim bakış açıma göre, istenmeyen sonuçlarla başarısız olmamanın klasik örneği, ffmpeg veya mplayer gibi büyük uygulamaları derlemektir. Bunlar, eğer mevcutlarsa kitaplıkları kullanacaklar, ancak olmasalar bile, bazı seçenekleri devre dışı bırakarak, yine de derleyecekler. Sorun şu ki, daha sonra herhangi bir format için destek olmadan derlendiğini keşfediyorsunuz, bu nedenle geri dönüp yeniden yapmanız gerekiyor.

./Configure'ın biraz etkileşimli olarak yaptığı başka bir şey de size uygulamanın sistemin neresinde kurulacağını özelleştirme seçeneği sunmaktır. Farklı dağıtımların / ortamların farklı kuralları vardır ve muhtemelen sisteminizin kurallarına bağlı kalmak isteyebilirsiniz. Ayrıca, yerel olarak da yüklemek isteyebilirsiniz (yalnızca kendiniz için). Geleneksel olarak ./configure ve make adımları kök olarak çalıştırılmazken, make install (yalnızca kendiniz için kurulmadıkça) kök olarak çalıştırılmalıdır.

Belirli dağıtımlar genellikle bu ./install.sh işlevselliğini dağıtıma duyarlı bir şekilde gerçekleştiren komut dosyaları sağlar - örneğin, kaynak RPM'ler + özellik dosyası + rpmbuild veya slackbuild'ler .

(Dipnot: Buna katılıyorum ./configure; make; make install; son derece sıkıcı olabilir.)

configure bağımlılıkların eksik olduğunu tespit ederse başarısız olabilir.

makeMakefile'da listelenen ilk hedef olan varsayılan bir hedefi çalıştırır. Genellikle bu hedef all, ancak her zaman değil. Yani make all installhedefin o olduğunu bilseydin yapabilirdin.

Yani ...

#!/bin/sh

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

veya:

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

Bu $*dahildir, çünkü çoğu zaman seçenekler sunmak zorundadır configure.

Ama neden insanların bunu kendilerinin yapmasına izin vermiyorsunuz? Bu gerçekten çok büyük bir kazanç mı?