Paketi Flashcards
Sta su menadzeri paketa?
Menadzeri paketa (package managers) sluze kada nam osnovne biblioteke nisu dovoljne.
O cemu treba da brine menadzer paketa?
Package manager koji bi trebao da radi sa C++-om bi trebao da brine o: razlicitim
kompajlerima, razlicitim platformama I razlicitim build sistemima.
Reproducable builds?
Ideja je ako imamo podesen build sistem, package
manager I sve ostalo, da imamo jednu jedinu komandu koja ce garantovati da na kom god
racunaru da smo, pod kojim god OS, da ce uvek da kompajlira nas kod korektno I da ce na svim
tim sistemima da ga kompajlira isto (da imamo iste mogucnosti, da su sve zavisnosti povucene
kako treba bez obzira na kojoj se platformi nalazimo).
Diamond problem
Imamo program A, koji koristi biblioteke B I C, koje obe zavise od biblioteke
D. Ako biblioteka B zahteva odredjenu verziju biblioteke D, a biblioteka C zahteva neku jos noviju
verziju biblioteke D. Ukoliko su te 2 verzije kompatibilne nece biti problema jer ce se uzeti novija,
ali ako nisu kompatibilni, izmedju B I D ce doci do kolizije. To je nesto sto package manager mora
da razresi (a vecina bi samo javila da ne moze to da razresi I da mi smislimo sta cemo da radimo).
Kod sistemskih paket manager-a ne moze ni da se desi jer se
uglavnom definisu samo jedne verzije odredjene biblioteke
Conan
Implementiran u python-u.
Conan omogucava da se koriste razliciti build sistemi (ne forsira samo CMake).
Sve vezano za Conan stavljamo u conanfile.txt (to nije obican txt fajl, ima svoju posebnu sintaksu).
Unutar conanfile.txt definisemo 2 sekcije: [requires] su biblioteke koje zahtevamo da koristimo u
projektu i [generators] koji se odnosi na to koji build sistem zelimo da koristimo (CMake).
Da bismo lokalno instalirali sve zavisnosti iz tog fajla: conan install
.. (pored te same biblioteke koju smo naveli, instaliraju se I sve njene zavisnosti, zatim zavisnosti
od tih zavisnosti tj. celo drvo zavisnosti).
Moramo na neki nacin CMake-u da kazemo da Conan postoji, zato u CMakeLists.txt pisemo:
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()
Prednosti i mane Conan-a
Karakteristike Conana:
- implementiran u python-u (laksi za skriptovanje od vcpkg-a)
- decentralizovan (ukoliko nam nisu dovoljni glavni repozitorojumi, mozemo da napravimo svoje I odlucujemo koje servere hocemo da koristimo a koje ne)
- postojanje glavnog repozitorijuma (apt). To znaci da postoji taj 1 glavni “sigurni” repo koji garantuje da sve biblioteke koje se nalaze na njemu ce medjusobno biti kompatibilne (njihove verzije). Tako da ako koristimo glavni repo, ne mozemo da dodjemo do problema dijamanta.
- Mane Conana:
- izmena CMakeLists.txt (moramo da obavestimo build sistem (CMake) da Conan postoji)
VCPKG
Primarna platforma su Windows-I (logicno)
Implementiran je u C++-u, uz CMake fajlove
Primarno je napravljen da radi sa CMake-om I ni sa cim drugim.
Ne postoji fajl u kojem definisemo zavisnosti, vec potrebne biblioteke instaliramo sa vcpkg install _______
Takodje ovde ne definisemo verzije. Ideja je da u celom repozitorijumu postoji jedna jedina verzija I da ona radi dobro sa svim drugim (centralizovan je).
Prednosti i mane VCPKG
Prednosti:
- ne moramo da menjamo CMakeLists.txt fajl ali zato prilikom pokretanja CMakea moramo da dodamo fleg: cmake .. / -DCMAKETOOLCHAIN_FILE= /putanja do fajla vcpkg.cmake
- ne moraju svi clanovi tima da koriste isti package manager (za razliku od Conana gde smo u CMakeLists.txt morali da kazemo koji package manager koristimo I onda svaki
clan tima prilikom kloniranja ima taj isti CMakeLists.txt fajl)
Mane:
- centralizovan?
NIX
Ideja je da ima dobre strane oba (i Conon-a i vcpkg-a) tj. da bude package manager koji moze da bude sistemski package manager (kao sto se vcpkg ponasa, kao sto je apt) ali i da dozvoljava instalaciju razlicitih verzija biblioteka u zavisnosti od potrebe programa.
Cilj je da bude:
- cist (pure) u smislu da instalacija necega utice na promenu ponasanja nekog drugog
paketa. (npr. imamo program koji zavisi od konkretnog binarnog fajla neke verzije,
azuriranje sistema ne treba da utice na ponasanje tog programa) Zato cemo imati
direktorijum nix/store u kojem ce se nalaziti svi paketi (sve verzije) koje su ikada
instalirane I onda ce za konkretan fajl uvek moci da procita tacnu verziju koja treba). Svaki paket ima svoju hes sumu (ime direktorijuma).
- deterministicki sistem (jednom napravljen paket, vecno postoji)
- composable (da ga je lako komponovati)
Prednost:
- reproducable builds (NIX garantuje, a Conon i vcpkg ne u potpunosti)
Razlike izmedju sistemskih menadzera paketa i sistema nix, conan…
Ako biblioteka sadrzi neki bag, time sto apdejtujemo sistem, apdejtovali smo I biblioteku (mana kod sistemskih npr. apt jer onda neki program samo moze da prestane sa radom)
A kod nix, conan-a ko se apdejtovala biblioteka, nasa verzija koda koristi staru, pa nece prestati sa radom.
Ogromna prednost sistemskih (apt) je sto se non stop instaliraju poslednje verzije
bitnih glavnih biblioteka (npr. OpenSSL), ali opet u slucaju velikih bagova to je njihova mana.