makepp_build_check - Online di Cloud

PROGRAM:

NAMA

makepp_build_check -- Bagaimana makepp memutuskan untuk membangun kembali file

DESKRIPSI

A: "arsitektur_independen", E: "benar-benar cocok", I: "abaikan_aksi", O: "hanya_aksi",
T: "target_baru"

Makepp menyimpan berbagai informasi tentang bagaimana file tertentu dibuat terakhir kali.
Informasi ini mencakup perintah build, arsitektur, dan tanda tangan semua
dependensi file. (Semua informasi yang disimpan ada di subdirektori .makepp of
setiap direktori.) Jika ada informasi ini yang berubah, makepp biasanya memutuskan untuk
membangun kembali file. Metode build check adalah yang mengontrol keputusan makepp untuk membangun kembali.
Ini memutuskan informasi mana yang harus dilihat, dan mana yang diabaikan.

Makepp biasanya memilih metode pemeriksaan build yang benar secara otomatis. Namun, Anda bisa
ubah metode tanda tangan untuk aturan individual dengan menggunakan pengubah :build_check di
aturan, atau untuk semua aturan dalam makefile dengan menggunakan pernyataan build_check, atau untuk semua
makefile sekaligus menggunakan opsi baris perintah -m atau --build-check-method.

Data yang digunakan untuk memutuskan tentang pembangunan kembali atau repositori atau impor cache build disimpan di
file info build internal. Anda dapat menampilkannya dengan makeppinfo, mppi. Di bawah masing-masing
metode memberikan contoh cara melihat kuncinya.

Membangun memeriksa metode termasuk in itu distribusi
Saat ini, ada lima metode pemeriksaan build yang disertakan dalam distribusi:

benar-benar cocok
Metode ini menggunakan tanggal modifikasi pada file sebagai tanda tangan. Itu membangun kembali
target kecuali semua kondisi berikut ini benar:

· Tanda tangan setiap dependensi sama seperti pada build terakhir.

· Tanda tangan setiap target sama seperti pada build terakhir (yaitu, tidak ada satu pun
telah mengacaukan target sejak makepp membangunnya).

· Perintah build tidak berubah.

· Arsitektur mesin (atau menurut pendapat Perl) tidak berubah.

"exact_match" adalah metode default kecuali Anda membangun kembali Makefile (lihat di bawah).
Ini adalah cara yang sangat andal untuk memastikan pembuatan yang benar, dan hampir selalu seperti itu
kamu ingin. Namun, itu memang memiliki beberapa efek samping yang mungkin mengejutkan:

· Jika Anda telah mengkompilasi dengan make tradisional, dan kemudian beralih ke makepp,
semuanya dikompilasi ulang saat pertama kali Anda menjalankan makepp.

· Jika Anda merusak informasi makepp tentang apa yang terjadi pada build terakhir (mis.
Anda menghapus subdirektori ".makepp", atau tidak menyalinnya saat Anda menyalin semuanya
lain), maka pembangunan kembali dipicu.

· Jika Anda mengganti file dengan versi yang lebih lama, pembangunan kembali dipicu. Ini adalah
biasanya apa yang Anda inginkan, tapi mungkin mengejutkan.

· Jika Anda memodifikasi file di luar kendali makepp (misalnya, Anda menjalankan
kompilasi perintah sendiri), maka makepp akan membangun kembali file waktu berikutnya. (Jika
Anda ingin menghindari ini, periksa opsi baris perintah "--dont-build".)

· File arsitektur-independen dibangun kembali ketika Anda beralih ke yang berbeda
Arsitektur. Ini biasanya tidak masalah, karena seringkali tidak memakan waktu lama
untuk membangun. Alasan mengapa semua file ditandai dengan arsitektur, bukan
hanya file biner, sering kali bahkan file ASCII berarsitektur-
bergantung. Misalnya, output dari program Solaris "lex" tidak dapat dikompilasi
Linux (atau setidaknya ini dulu benar terakhir kali saya mencobanya).

Konkretnya, file tidak akan dibangun kembali, atau dapat diambil dari repositori atau build
cache, jika output perintah berikut tetap sama, yaitu cocok dengan tanda tangan dari
dependensi:

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

arsitektur_independen
Metode "architecture_independent" sama dengan "exact_match" hanya saja
tidak memeriksa arsitektur. Ini dapat berguna untuk file yang tidak bergantung pada arsitektur,
yang tidak perlu dibangun kembali saat Anda beralih ke arsitektur yang berbeda. Untuk
contoh, Anda mungkin tidak perlu menjalankan ulang "bison" di Solaris jika Anda sudah menjalankannya
Linux.

Metode "architecture_independent" paling baik digunakan dengan menentukannya menggunakan
Pengubah ":build_check architecture_independent" ke setiap aturan yang menghasilkan
file independen arsitektur. Makepp secara default tidak pernah menganggap file apa pun adalah
arsitektur independen, karena bahkan .c file dapat bergantung pada arsitektur. Untuk
contoh, output Solaris lex tidak akan dikompilasi di Linux, atau setidaknya itu
tidak akan terakhir kali saya mencoba. Jadi, Anda harus menentukan metode pemeriksaan build ini secara manual untuk
file apa pun yang benar-benar tidak bergantung pada arsitektur.

Konkretnya, file tidak akan dibangun kembali, atau dapat diambil dari repositori atau build
cache, jika output perintah berikut tetap sama, yaitu cocok dengan tanda tangan dari
dependensi:

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

abaikan_aksi
Metode "ignore_action" sama dengan "exact_match" kecuali tidak memeriksa
string tindakan (perintah). Terkadang sebuah perintah bisa berubah dan Anda tidak mau
memaksa membangun kembali.

Misalnya, Anda mungkin ingin secara eksplisit memasukkan tanggal ke dalam perintah Anda untuk login ketika
build selesai, tetapi Anda tidak ingin memaksa membangun kembali setiap kali perintahnya
dieksekusi. Sebagai contoh,

BUILD_DATE := $(tanggal kulit)

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

Ini akan dikompilasi tanggal_cap.c dengan cap tanggal pembuatan terakhir, tetapi tidak akan memaksa
kompilasi ulang ketika tanggal berubah. Sayangnya, jika ada hal lain tentang tautan
perubahan perintah (misalnya, Anda mengubah opsi tautan), itu juga tidak akan memicu pembangunan kembali.

Ini juga berguna dalam hubungannya dengan $(changed_inputs) atau $? variabel untuk
tindakan yang hanya memperbarui target, daripada membangunnya kembali dari awal. Untuk
contoh, Anda dapat memperbarui file .a seperti ini:

libmine.a : *.o : build_check abaikan_action
$(AR) dan $(output) $(input_berubah)

Ini sebagian besar masih akan berfungsi jika Anda lupa menentukan ": build_check
abaikan_action". Namun, anggaplah tidak ada file .o yang berubah. Perintahnya
sekarang akan menjadi "ar ru libmine.a" yang mungkin berbeda dari yang terakhir kali
(misalnya, "ar ru libmine.a buggy_module.o"), jadi makepp akan menjalankan perintah. Di dalam
kasus, perintah tidak akan melakukan apa pun kecuali membuang waktu.

Membuat file .a seperti ini tidak disarankan, karena dapat meninggalkan file .o basi di dalamnya
arsip. Jika Anda menghapus file sumber, file .o masih berada di dalam file .a,
dan ini dapat menyebabkan build yang salah. Lebih baik membuat file .a seperti ini:

libmine.a : *.o
&rm $(keluaran)
$(AR) ru $(keluaran) $(masukan)

Konkretnya, file tidak akan dibangun kembali, atau dapat diambil dari repositori atau build
cache, jika output perintah berikut tetap sama, yaitu cocok dengan tanda tangan dari
dependensi:

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

target_baru
Metode "target_newer" hanya terlihat pada tanggal file. Jika ada ketergantungan lebih
baru dari target, target dibangun kembali. Ini adalah algoritma yang
Unix tradisional membuat kegunaan utilitas.

Metode "target_newer" tidak seaman metode "exact_match" karena tidak akan
memicu pembangunan kembali jika Anda mengubah perintah build, atau jika Anda mengganti file dengan
versi yang lebih lama. Terkadang juga bisa bingung jika jam tidak sesuai
disinkronkan. Misalnya, jika suatu file entah bagaimana mendapatkan tanggal 4 Juni 2048, maka
antara sekarang dan 2048, setiap file yang bergantung pada file itu akan dibangun kembali meskipun
filenya tidak berubah. Juga beralih ke arsitektur yang berbeda tidak akan memicu
membangun kembali. Ini mencegah pengambilan target aturan dari cache build, karena tidak ada
tanda tangan unik yang dapat dikaitkan dengan rangkaian pasangan tanpa akhir yang memenuhi
hubungan lebih baru dari.

Tetapi ada beberapa kasus di mana Anda mungkin ingin menggunakan metode "target_newer":

· Ketika masuk akal bagi pengguna untuk membuat file di luar kendali makepp.
Mungkin contoh paling umum adalah perintah yang menghasilkan makefile
itu sendiri, yaitu prosedur konfigurasi otomatis. Pengguna biasanya mengeluarkan konfigurasi
perintah secara manual, tetapi makefile sering memiliki cara untuk memperbarui sendiri
secara otomatis. Dalam hal ini, kami tidak ingin memaksa makefile untuk membangun kembali
sendiri jika pengguna mengetikkan perintah secara manual, jadi metode "target_newer" adalah
lebih tepat daripada metode "exact_match". Faktanya, jika makepp mencoba
buat makefile, itu membuat "target_newer" metode default sampai selesai
membangun makefile.

· Ketika masuk akal bagi pengguna untuk memodifikasi file setelah makepp membuatnya. Untuk
contoh, jika file tidak ada, Anda mungkin ingin menyalinnya dari pusat
lokasi, atau periksa dari repositori; tetapi pengguna harus diizinkan untuk
memodifikasinya. Jika Anda menggunakan metode pemeriksaan build "exact_match" default, makepp akan
mendeteksi bahwa pengguna telah mengubah file dan karenanya akan memaksa salinan baru dari
lokasi pusat atau checkout baru, menghapus perubahan pengguna.

Jika Anda perlu memeriksa stempel waktu secara manual, lihat contoh makeppinfo untuk cara mendapatkannya
jalur setiap ketergantungan.

hanya_tindakan
Metode "only_action" yang sangat spesifik hanya akan menjalankan tindakan jika perintah
string berbeda dari terakhir kali dieksekusi. Sebagai contoh,

$(ROOT)/termasuk/%.h : %.h
&ln -fr $(masukan) $(keluaran)

menerbitkan file, tetapi tidak mengulanginya saat file berubah. Perhatikan bahwa &ln
perintah sudah terpasang dan dengan demikian murah, tetapi makepp masih harus membayar dan memantau a
proses untuk melakukan seluruh tindakan. Jadi, jika Anda memiliki banyak file untuk dipublikasikan, di sana
masih merupakan keuntungan. Sebenarnya kami tidak menentukan metodenya, karena, kapan targetnya
adalah tautan simbolis, pemeriksaan build ini digunakan secara otomatis. Anda hanya perlu
tentukan untuk perintah lain yang hanya bergantung pada perintah (yang biasanya
berisi nama-nama input):

%.list : .x : build_check only_action
&echo $(masukan) -o $(keluaran)

Konkretnya, file tidak akan dibangun kembali, atau dapat diambil dari repositori atau build
cache, jika output perintah berikut tetap sama, yaitu cocok dengan tanda tangan dari
dependensi:

file mppi -kCOMMAND

Metode pemeriksaan build lainnya dimungkinkan. Anda dapat menulis metode pemeriksaan bangunan Anda sendiri dengan
membuat modul "Mpp::BuildCheck::MyMethod". Baca dokumentasi di
Mpp/BuildCheck.pm dalam distribusi makepp. Kemungkinan besar, Anda akan menginginkan build check Anda
metode untuk mewarisi dari "Mpp::BuildCheck::exact_match", jadi baca juga dokumentasinya.

Lebih sering berguna memodifikasi mekanisme tanda tangan daripada memodifikasi pemeriksaan build
mekanisme secara langsung. Sebelum Anda mengubah mekanisme pemeriksaan build, lihat apakah masalah Anda
lebih baik dilayani dengan mengubah tanda tangan (lihat makepp_signatures untuk detailnya).

Berikut adalah beberapa alasan mengapa metode pemeriksaan build kustom mungkin berguna:

· Jika Anda ingin makepp mengabaikan bagian dari perintah. Misalnya, jika Anda memiliki perintah
di makefile Anda seperti ini:

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

Anda mungkin ingin makepp tidak memaksakan pembangunan kembali jika "$(REMOTE_MACHINE)" berubah. Anda
dapat memodifikasi metode "exact_match" sehingga ia mengetahui tentang perintah ssh dan mengabaikan
nama mesin. Periksa :dispatch untuk cara lain untuk mencapai itu.

Gunakan makepp_build_check online menggunakan layanan onworks.net