Build Rule — build tizimida ma’lum outputlarni qaysi inputlar, vositalar va buyruq yoki action yordamida yaratish kerakligini deklarativ yoki dasturiy ko‘rsatadigan birlik.
Graphdagi o‘rni
Rule input, output, toolchain, command, environment va dependency edge’larini belgilaydi. Build graph scheduler output talab qilinganda kerak rule’larni topological tartibda bajaradi. Bir outputga ikki mustaqil rule egalik qilsa konflikt yuz beradi.
Dependency turlari
Explicit dependency source fayllar kabi oldindan ma’lum; discovered dependency compiler depfile orqali aniqlangan header bo‘lishi mumkin. Order-only dependency bajarilish tartibini belgilaydi, lekin kontent o‘zgarishi har doim outputni invalidatsiya qilmasligi mumkin.
Hermetik bajarish
Hermetic rule faqat e’lon qilingan inputlarni ko‘radi va faqat e’lon qilingan outputlarni yozadi. Sandbox yashirin /usr/include, home config yoki tarmoqdan foydalanishni aniqlaydi. Shunda cache key to‘liq va remote execution mumkin bo‘ladi.
Parametrli rule
Rule parametrdan ko‘p target hosil qilishi mumkin. Macro yoki aspect umumiy policy qo‘shadi, ammo graphni yashirin murakkablashtirmasligi kerak. Toolchain resolution platformaga mos compiler va runtime’ni tanlaydi.
Incremental hisob
Incremental buildda rule action key o‘zgarmasa va output cache’da bo‘lsa bajarilmaydi. Dynamic input e’lon qilinmasa eski output qolishi mumkin; “clean build ishlaydi” incremental correctnessni isbotlamaydi.
Sinov
Test rule’ni toza sandboxda, bo‘sh cache’da va inputlarni bittadan o‘zgartirib bajaradi. Declared outputdan tashqari yozuv hamda undeclared read audit qilinadi.
Amaliy boshqaruv
Build Rule implementatsiyasida declared input-output graph alohida va versiyalangan holat sifatida yuritiladi. Qaror uchun zarur inputlar yashirin global taxminga aylantirilmaydi: platforma, konfiguratsiya, identity yoki memory-order sharti tegishli obyekt bilan bog‘lanadi. Shu sabab incremental yangilanish, context almashishi yoki parallel hodisada eskirgan ma’lumotdan foydalanish kamayadi. Debug rejim qarorni hosil qilgan edge, state transition va parametrlarni ko‘rsatadi; production log esa maxfiy qiymatlarni xom shaklda yozmaydi.
Muhim xato sinfi — undeclared read yoki bir outputga ikki owner. Bunday vaziyatda tizim optimistik tarzda davom etmaydi: semantikaga qarab konservativ fallback, bounded retry, taskni bloklash yoki aniq error tanlanadi. Timeout correctness isboti emas; u faqat operatsion limitdir. Queue membership, reference count, lock ownership va visibility kabi invariantlar state bilan atomik yangilanadi. Cancellation yoki failure o‘rtada yuz bersa qisman o‘zgargan holat cleanup protokoli orqali tiklanadi.
Sifat nazorati sandbox hamda incremental rebuild orqali bajariladi. Test normal yo‘ldan tashqari bo‘sh navbat, bitta element, yuqori contention, timeout bilan bir vaqtdagi wakeup, resurs limiti va platforma variantlarini qamraydi. To‘g‘rilik performance’dan alohida tekshiriladi; keyin throughput, p99 latency, context switch, cache miss yoki artefakt hajmi kabi mavzuga mos ko‘rsatkichlar baseline bilan solishtiriladi. Topilgan minimal interleaving yoki kirish regressiya to‘plamida doimiy saqlanadi.
Rule nomi va target label build graphda barqaror identity beradi. Output path konfiguratsiya va platformaga ko‘ra ajratiladi, shunda debug hamda release actionlari bir faylni yozmaydi. Rule failure qisman yaratilgan outputni valid deb qoldirmaydi; temporary katalogdan atomic rename yoki declared cleanup ishlatiladi.
Bog‘liq tushunchalar
build graph, dependency, build action, sandbox, toolchain, incremental build