makepp_build_check - Dalam talian dalam Awan

JADUAL:

NAMA

makepp_build_check -- Bagaimana makepp memutuskan untuk membina semula fail

DESCRIPTION

A: "bebas_seni bina", E: "padanan_tepat", I: "abaikan_tindakan", O: "hanya_tindakan",
T: "target_newer"

Makepp menyimpan pelbagai maklumat tentang cara mana-mana fail tertentu dibina pada kali terakhir.
Maklumat ini termasuk arahan binaan, seni bina dan tandatangan semua
kebergantungan fail. (Semua maklumat yang disimpan adalah dalam subdirektori .makepp of
setiap direktori.) Jika mana-mana maklumat ini telah berubah, makepp biasanya memutuskan untuk
membina semula fail. Kaedah semakan binaan ialah kaedah yang mengawal keputusan makepp untuk membina semula.
Ia memutuskan maklumat yang mana untuk dilihat, dan yang harus diabaikan.

Makepp biasanya memilih kaedah semakan binaan yang betul secara automatik. Walau bagaimanapun, anda boleh
tukar kaedah tandatangan untuk peraturan individu dengan menggunakan :build_check pengubah pada
peraturan, atau untuk semua peraturan dalam fail make dengan menggunakan penyataan build_check, atau untuk semua
makefiles sekali gus menggunakan pilihan baris arahan -m atau --build-check-method.

Data yang digunakan untuk memutuskan tentang binaan semula atau repositori atau import cache binaan disimpan dalam
fail maklumat binaan dalaman. Anda boleh memaparkannya dengan makeppinfo, mppi. Di bawah setiap satu
kaedah memberikan contoh bagaimana untuk melihat kuncinya.

Membina menyemak kaedah dimasukkan in yang pengedaran
Pada masa ini, terdapat lima kaedah semakan binaan termasuk dalam pengedaran:

padanan_tepat
Kaedah ini menggunakan tarikh pengubahsuaian pada fail sebagai tandatangan. Ia membina semula
sasaran melainkan semua syarat berikut adalah benar:

· Tandatangan setiap kebergantungan adalah sama seperti pada binaan terakhir.

· Tandatangan setiap sasaran adalah sama seperti pada binaan terakhir (iaitu, tiada siapa
telah mengacaukan sasaran sejak makepp membinanya).

· Arahan bina tidak berubah.

· Seni bina mesin (atau apa yang difikirkan oleh Perl) tidak berubah.

"exact_match" ialah kaedah lalai melainkan anda membina semula Makefile (lihat di bawah).
Ini ialah cara yang sangat boleh dipercayai untuk memastikan binaan yang betul, dan hampir selalunya
awak mahu. Walau bagaimanapun, ia mempunyai beberapa kesan sampingan yang mungkin mengejutkan:

· Jika anda telah menyusun dengan pembuatan tradisional, dan kemudian beralih kepada makepp,
semuanya disusun semula pada kali pertama anda menjalankan makepp.

· Jika anda merosakkan maklumat makepp tentang perkara yang berlaku pada binaan terakhir (cth,
anda memadamkan subdirektori ".makepp", atau jangan salinnya apabila anda menyalin semuanya
lain), maka pembinaan semula dicetuskan.

· Jika anda menggantikan fail dengan versi yang lebih lama, binaan semula akan dicetuskan. Ini adalah
biasanya apa yang anda mahukan, tetapi ia mungkin mengejutkan.

· Jika anda mengubah suai fail di luar kawalan makepp (cth, anda menjalankan fail
arahan kompilasi sendiri), kemudian makepp akan membina semula fail pada masa akan datang. (Jika
anda ingin mengelakkan ini, lihat pilihan baris arahan "--dont-build".)

· Fail bebas seni bina dibina semula apabila anda bertukar kepada fail lain
seni bina. Ini biasanya tidak menjadi masalah, kerana mereka selalunya tidak mengambil masa yang lama
bina. Sebab mengapa semua fail ditandakan dengan seni bina, bukannya
hanya fail binari, adakah selalunya fail ASCII adalah seni bina-
bergantung. Sebagai contoh, output daripada program "lex" Solaris tidak akan dikompilkan
Linux (atau sekurang-kurangnya ini adalah benar pada kali terakhir saya mencubanya).

Secara konkrit, fail tidak akan dibina semula, atau boleh diambil dari repositori atau binaan
cache, jika output arahan berikut kekal sama, iaitu sepadan dengan tandatangan
kebergantungan:

mppi -k'COMMAND ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' fail

seni bina_bebas
Kaedah "architecture_independent" adalah sama dengan "exact_match" kecuali ia berlaku
tidak menyemak seni bina. Ini boleh berguna untuk fail bebas seni bina,
yang tidak perlu dibina semula apabila anda bertukar kepada seni bina yang berbeza. Untuk
contoh, anda mungkin tidak perlu menjalankan semula "bison" pada Solaris jika anda sudah menjalankannya
Linux.

Kaedah "architecture_independent" paling baik digunakan dengan menyatakannya menggunakan
":build_check architecture_independent" pengubah suai kepada setiap peraturan yang menghasilkan
fail bebas seni bina. Makepp secara lalai tidak pernah menganggap mana-mana fail adalah
seni bina bebas, kerana walaupun .c fail boleh bergantung kepada seni bina. Untuk
contoh, output Solaris lex tidak akan disusun di bawah Linux, atau sekurang-kurangnya ia
tidak akan kali terakhir saya mencuba. Oleh itu, anda mesti secara manual menentukan kaedah semakan binaan ini
sebarang fail yang benar-benar bebas seni bina.

Secara konkrit, fail tidak akan dibina semula, atau boleh diambil dari repositori atau binaan
cache, jika output arahan berikut kekal sama, iaitu sepadan dengan tandatangan
kebergantungan:

mppi -k'COMMAND SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' fail

abaikan_tindakan
Kaedah "ignore_action" adalah sama dengan "exact_match" kecuali ia tidak menyemak
rentetan tindakan (arahan). Kadang-kadang arahan boleh berubah dan anda tidak mahu
paksa bina semula.

Sebagai contoh, anda mungkin mahu meletakkan tarikh secara eksplisit ke dalam arahan anda untuk log apabila
bina telah dilakukan, tetapi anda tidak mahu memaksa bina semula setiap kali arahan itu
dilaksanakan. Sebagai contoh,

BUILD_DATE := $(tarikh cangkang)

my_program : $(MODUL).o
$(CXX) $(inputs) -DBUILD_DATE="\"$(BUILD_DATE)\"" date_stamp.c -o $(output)

Ini akan menyusun cop_tarikh.c dengan cop tarikh binaan terakhir, tetapi tidak akan memaksa a
susun semula apabila tarikh berubah. Malangnya, jika sesuatu yang lain tentang pautan
perubahan arahan (cth, anda menukar pilihan pemaut), ia juga tidak akan mencetuskan pembinaan semula.

Ini juga berguna bersama dengan $(changed_inputs) atau $? pembolehubah untuk
tindakan yang hanya mengemas kini sasaran, bukannya membina semula dari awal. Untuk
contoh, anda boleh mengemas kini fail .a seperti ini:

libmine.a : *.o : build_check ignore_action
$(AR) ru $(output) $(changed_inputs)

Ini kebanyakannya akan berfungsi jika anda terlupa untuk menentukan ": build_check
ignore_action". Walau bagaimanapun, andaikan tiada satu pun fail .o telah berubah. Perintah
kini akan menjadi "ar ru libmine.a" yang mungkin berbeza daripada kali terakhir
(cth, "ar ru libmine.a buggy_module.o"), jadi makepp akan menjalankan arahan. Di dalam ini
kes, arahan itu tidak akan melakukan apa-apa kecuali membuang masa.

Membina fail .a seperti ini tidak digalakkan, kerana ia boleh meninggalkan fail .o basi di dalamnya
arkib. Jika anda memadamkan fail sumber, fail .o masih berada di dalam fail .a,
dan ini boleh menyebabkan binaan yang salah. Lebih baik membina fail .a seperti ini:

libmine.a : *.o
&rm $(output)
$(AR) ru $(output) $(input)

Secara konkrit, fail tidak akan dibina semula, atau boleh diambil dari repositori atau binaan
cache, jika output arahan berikut kekal sama, iaitu sepadan dengan tandatangan
kebergantungan:

mppi -k'ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' fail

target_newer
Kaedah "target_newer" hanya melihat pada tarikh fail. Jika ada pergantungan yang lebih
baru-baru ini daripada sasaran, sasaran dibina semula. Ini adalah algoritma yang
Unix tradisional membuat kegunaan utiliti.

Kaedah "target_newer" tidak selamat seperti kaedah "exact_match" kerana ia tidak akan
mencetuskan binaan semula jika anda menukar arahan binaan, atau jika anda menggantikan fail dengan fail
versi lama. Kadang-kadang juga ia boleh menjadi keliru jika jam tidak betul
disegerakkan. Sebagai contoh, jika fail entah bagaimana mendapat tarikh 4 Jun 2048, maka
antara sekarang dan 2048, setiap fail yang bergantung pada fail itu akan dibina semula walaupun
fail tidak berubah. Juga menukar kepada seni bina yang berbeza tidak akan mencetuskan a
membina semula. Ia menghalang pengambilan sasaran peraturan daripada cache binaan, kerana tiada
tandatangan unik yang boleh dikaitkan dengan set pasangan yang tidak berkesudahan memenuhi
hubungan yang lebih baru daripada.

Tetapi terdapat beberapa kes di mana anda mungkin mahu menggunakan kaedah "target_newer":

· Apabila adalah munasabah untuk pengguna membina fail di luar kawalan makepp.
Mungkin contoh yang paling biasa ialah arahan yang menghasilkan fail make
itu sendiri, iaitu, prosedur autokonfigurasi. Pengguna biasanya mengeluarkan konfigurasi
arahan secara manual, tetapi makefiles selalunya mempunyai cara untuk mengemas kini diri mereka sendiri
secara automatik. Dalam kes ini, kami tidak mahu memaksa makefile untuk membina semula
sendiri jika pengguna menaip arahan secara manual, jadi kaedah "target_newer" adalah
lebih sesuai daripada kaedah "exact_match". Malah, jika makepp cuba
membina fail make, ia menjadikan "target_newer" kaedah lalai sehingga ia selesai
membina fail make.

· Apabila adalah munasabah untuk pengguna mengubah suai fail selepas makepp membinanya. Untuk
contoh, jika fail tidak wujud, anda mungkin mahu menyalinnya dari pusat
lokasi, atau semaknya daripada repositori; tetapi pengguna harus dibenarkan
mengubah suainya. Jika anda menggunakan kaedah semakan binaan "exact_match" lalai, makepp akan
mengesan bahawa pengguna telah menukar fail dan oleh itu ia akan memaksa salinan baharu daripadanya
lokasi pusat atau pembayaran baru, menghapuskan perubahan pengguna.

Jika anda perlu menyemak cap masa secara manual, lihat contoh makeppinfo untuk mendapatkannya
laluan setiap kebergantungan.

only_action
Kaedah "only_action" yang sangat khusus hanya akan melaksanakan tindakan jika arahan itu
rentetan berbeza daripada kali terakhir ia dilaksanakan. Sebagai contoh,

$(ROOT)/include/%.h : %.h
&ln -fr $(input) $(output)

menerbitkan fail, tetapi tidak mengulanginya apabila fail berubah. Ambil perhatian bahawa &ln
arahan dibina dan dengan itu murah, tetapi makepp masih perlu berhenti dan memantau a
proses untuk melaksanakan keseluruhan tindakan. Jadi jika anda mempunyai banyak fail untuk diterbitkan, di sana
masih ada faedah. Sebenarnya kami tidak menyatakan kaedah, kerana, apabila sasaran
ialah pautan simbolik, semakan binaan ini digunakan secara automatik. Anda hanya perlu
tentukan ia untuk arahan lain yang bergantung semata-mata pada arahan (yang biasanya
mengandungi nama input):

%.list : %.x : build_check only_action
&echo $(inputs) -o $(output)

Secara konkrit, fail tidak akan dibina semula, atau boleh diambil dari repositori atau binaan
cache, jika output arahan berikut kekal sama, iaitu sepadan dengan tandatangan
kebergantungan:

fail mppi -kCOMMAND

Kaedah semakan binaan lain adalah mungkin. Anda boleh menulis kaedah semak binaan anda sendiri dengan
mencipta modul "Mpp::BuildCheck::MyMethod". Baca dokumentasi dalam
Mpp/BuildCheck.pm dalam pengedaran makepp. Kemungkinan besar, anda akan mahukan semakan binaan anda
kaedah untuk mewarisi daripada "Mpp::BuildCheck::exact_match", jadi baca dokumentasinya juga.

Ia lebih berguna untuk mengubah suai mekanisme tandatangan daripada mengubah suai semakan binaan
mekanisme secara langsung. Sebelum anda menukar mekanisme semakan binaan, lihat sama ada masalah anda adalah
disampaikan dengan lebih baik dengan menukar tandatangan (lihat makepp_signatures untuk butiran).

Berikut ialah beberapa sebab mengapa kaedah semakan binaan tersuai mungkin berguna:

· Jika anda mahu makepp mengabaikan sebahagian daripada arahan. Sebagai contoh, jika anda mempunyai arahan
dalam makefile anda seperti ini:

xo: xc
ssh $(REMOTE_MACHINE) cc $< -o $@

anda mungkin mahu makepp tidak memaksa bina semula jika "$(REMOTE_MACHINE)" berubah. awak
boleh mengubah suai kaedah "exact_match" supaya ia mengetahui tentang arahan ssh dan mengabaikan
nama mesin. Semak :dispatch untuk cara lain untuk mencapainya.

Gunakan makepp_build_check dalam talian menggunakan perkhidmatan onworks.net