Build target — build tizimida yaratiladigan artefakt yoki bajariladigan mantiqiy vazifani ifodalovchi nomlangan birlikdir. Executable, kutubxona, container image, test to‘plami va generated source alohida target bo‘lishi mumkin. Target o‘z inputlari, dependencylari, build actioni va natijalarini deklaratsiya qilib, katta loyihani boshqariladigan qismlarga ajratadi.
Target tavsifi
Oddiy target source fayllar ro‘yxati, compiler optionlari va output nomidan iborat. Murakkab target boshqa targetlarning public header, library yoki generated ma’lumotiga tayanadi. Build system avval dependencylarni tayyorlab, keyin joriy actionni bajaradi.
Target label global yoki package doirasida noyob bo‘ladi. U file path bilan bir xil bo‘lishi shart emas: //server:api kabi label loyiha iyerarxiyasi va mantiqiy nomni ifodalaydi. Barqaror label avtomatlashtirish va developer buyruqlarini source joylashuvidan qisman ajratadi.
Input va output
Target o‘qiydigan source, config, tool va dependency deklaratsiya qilinadi. Environment variable yoki system library yashirin input bo‘lib qolsa, bir mashinadagi muvaffaqiyat boshqa muhitda takrorlanmasligi mumkin. Outputlar ham aniq nomlanadi va boshqa targetlar ularga deklarativ murojaat qiladi.
Bitta target bir nechta output, masalan binary va debug symbol hosil qilishi mumkin. Ularning qaysi biri public artefakt ekanini provider yoki output group bildiradi. Temporary fayllar private working directoryda qoladi va boshqa action ularga tayanmaydi.
Granulyarlik
Juda katta target kichik source o‘zgarishida butun modulni rebuild qiladi va parallelizmni kamaytiradi. Juda mayda target esa graph, konfiguratsiya va scheduling overheadini oshiradi. Granulyarlik ownership, API chegarasi, kompilyatsiya narxi va qayta foydalanishga qarab tanlanadi.
Kutubxona target public interfeysni, implementation detail esa private dependencylarni ajratadi. Consumer faqat public dependencyga kirsa, ichki o‘zgarishning rebuild doirasi cheklanadi. Target chegarasini arxitektura chegarasi bilan moslashtirish couplingni ko‘rinadigan qiladi.
Konfiguratsiya variantlari
Bir target debug va release, turli CPU arxitekturasi yoki operatsion tizim uchun boshqa variant hosil qilishi mumkin. Variantlar alohida label bo‘lishi yoki build configuration orqali tanlanishi mumkin. Cache key konfiguratsiyani qamrab oladi; aks holda debug object release buildga noto‘g‘ri aralashadi.
Conditional dependency platformaga qarab tanlanadi. Shartlar haddan tashqari ko‘paysa targetni tushunish va test qilish qiyinlashadi. Har supported konfiguratsiya CI matrixda kamida tegishli darajada build qilinadi.
Test target
Test target test binary bilan birga data file, fixture va runtime environmentni ham ta’riflaydi. Testning boshqa servisga ehtiyoji deklaratsiya qilinmasa, u lokal holatga bog‘liq flaky testga aylanadi. Sharding va timeout metadata schedulerga testni samarali bajarishga yordam beradi.
Phony yoki aggregate target o‘zi fayl yaratmay, all, check kabi dependencylar guruhini ishga tushiradi. Uning up-to-date semantikasi file targetdan farq qiladi va tasodifan ayni nomli fayl bilan to‘qnashmasligi kerak.
Visibility va ownership
Target visibility qaysi package yoki modul uning public dependency bo‘la olishini cheklaydi. Ichki targetni butun repositoryga ochish consumerlarning implementation detailga bog‘lanishiga sabab bo‘ladi. Keyingi refactor esa kutilmagan ko‘p targetni buzadi.
Ownership metadata target uchun review va support javobgarligini bildiradi. Code owner o‘zgarishning API, security va release ta’sirini baholaydi. Target deprecated bo‘lsa replacement label, migration muddati va remaining consumerlar query orqali ko‘rsatiladi. Alias nom ko‘chirishni yengillashtirishi mumkin, ammo doimiy alias zanjiri graphni chalkashtiradi. Stable target contract source file joylashuvidan ko‘ra consumer uchun muhimroq hisoblanadi.
Bog‘liq tushunchalar
Build system, Build graph, Dependency, Artefact, Compilation unit, Build configuration, Test target