[FreeBSD] openbsd make build

[Adam Szilveszter]

Kedves Feri!

Nem gondoltam, hogy ekkora izgalmat idezek elo nalad ezzel a levellel, ha
tudom nem irom meg. Korabbi leveleimbol tudhatod, hogy nagy tiszteloje
vagyok a NetBSD rendszernek es a projektnek. De mint mar a multkor is
amikor ez felmerult irtam, ez nem akadalyoz meg abban, hogy kritikaval
eljek ott ahol az szerintem indokolt. Sot, ha valamit remenytelenul
rossznak tartok, azt nem kritzalom csak otthagyom. Nagyon jo dolog,
tenyleg, hogy a NetBSD olyan sok fele platformon megy de nem latom, hogy
ezt mi modon akadalyozna vagy hatraltatna egy kicsit jobban osszefogott
build mechanizums. Megkockaztatom, hogy a release engineernek is konnyebb
dolga lenne mikor csinaljak a kovetkezo verziot.

Mert mirol is van szo:

A FreeBSD-n, noha elvileg szinten lehet olyat csinalni, hogy csinalsz egy
uj kernelt rebootolsz es aztan cd /usr/src ; make depend all install de ez
nagyon nem ajanlott. Van, lehet olyan eset, hogy sikerul, de konnyen lehet,
hogy nem. Azoknak a problemaknak a kezelesere, amik ebbol adodnak szuletett
meg a make buildworld. Mit tesz ez a folyamat:

1) Eloszor is lefordit, meg szigoruan a host (tehat az a gep, *ahol* es nem
*amire* forditasz) konyvtarai es headerjei es forditoja segitsegevel nehany
olyan programot, amik a forditasi folyamat folyaman fognak kelleni, de
utana nem, ezert az se baj, ha mas platformra vannak, mint a target (ahova
forditasz) mert nem ott kel mukodniuk.

Pl ilyen a yacc, vagy a fortune strfile nevu segedprogramja (jo ennel
fontosabb program is van a vilagon, de akkor is kozte van:-) De ilyen az
/usr/sbin/config is, vagy legujabban a kbdcontrol es a groff, mert voltak
gondok azzal, hogy a -CURRENT-en levo kbdcontrol olyan opciokat is tud,
amit a -STABLE beli nem, ergo ha 4.x-rol akarsz -CURRENTre frissiteni,
megszivod, mert elszall, es a groff is tartalmazhat jelentos ujdonsagokat
ahhoz kepest, ami a te rendszereden van, ami a manok kezelesere lehet
negativ hatassal. Utana ezeket bepakolja a /usr/obj megfelelo alkonyvtaraba
ahol egyebkent egy teljes rendszertukor letezik, kulon szedve a
platformspecifikus (/usr/obj/usr/src/i386) es a nem (/usr/obj/usr/src)
dolgokat. A muvelet tovabbi reszeben mar ezeket es nem a rendszeren levo,
potencialisan regi valtozataikat fogja hasznalni.

Ez az un bootstrap tools fazis.

2) Konyvtarstruktura elokeszitese.

Ebben a fazisban eloszor kitakaritja az /usr/obj alatti strukturabol az
eddig bennemaradt regi dolgokat, majd ha nem leteznek, letrehozza a
megfelelo konyvtarakat, pl /usr/obj/usr/src/bin/test az /usr/src/bin/test
szamara. Ez jol kulontartja a forditas soran keletkezett dolgokat a
forrastol, es egyszeruve teszi a takaritast a vegen: rm -rf /usr/obj/*

3) Az un cross tools keszitese. Ezek azok, amik akkor jutnak szerephez
foleg, ha mas platform a target, mint a host. De neha egyekent is szerepuk
lehet. Pl ebben a fazisban epul meg a libperl, a miniperl, a gcc, a
binutils. Igy egyszeru csak annyit mondani, hogy a target egy alpha, a host
egy i386, es erre fel egy i386-alpha cross compiler epul pl meg. Ha a ket
platoform azonos, meg mindig hasznos lehet, mert pl egy gcc upgrade eseten
az uj gcc mar itt megjelenik a forditas soran es ezentul ezeket es nem a
rendszeren levo valtozatukat fogja hasznalni a forditas akkor is, ha a ket
platform egyezik. Igy az uj kod tartalmazhat mas program eseteben olyan
reszeket is, amik mar csak egy uj gcc-vel fordulnak le es megis minden
kvazi magatol mukodni fog. Az igy elkeszult programok is az /usr/obj alatt
foglalnak helyet.

4) Sor kerul az include file-ok bemasolasara az /usr/obj ala a forras
kulonbozo konyvtaraibol, abban a hierarchiaban, amiben egy "elo" rendszeren
is talalhatok lennenek, tehat /usr/obj/usr/src/i386/usr/include, mivel itt
mar hatarozotttan csak a target platformra epitunk. Innentol tehat a
tovabbi forditasnal a host include file-jai figyelmen kivul maradnak
joreszt. 

5) Konyvtarak epitese. A most forditott gcc-vel es binutils-al, a most
bemasolt include file-okkal, a target platformra. Az epites tobb korben
megy, mert amint egy kor kesz, a konyvtarak az /usr/obj megfelelo helyere
kerulnek es a kesobbi konyvtarak mar ezektol is fuggenek. Most kb harom
kornel tartunk, de mar reg nem szamolom:-)

Tehat ezen a ponton ott tartunk, hogy az /usr/obj platformfuggo
konyvtaraban mar leteznek a targetre valo include-k es libraryk es van egy
(esetleg cross) de mindenkeppen uj compiler toolchain.

6) Make depend. A folyamat ezek utan vegighuz *minden* konyvtaron es
mindenhol make dependet csinal, kiveve a konyvtarak eseteben amiket most
csinalt meg.

7) Build all: A tulajdonkeppeni epites, a (cross) compilerrel, a target
library-kal es include-okkal, az /usr/obj megfelelo alkonyvtaraba helyezve
az eredmenyt.

Kesz.

Most mar gondolom erthetobb, miert vagyok en annyira nagy hive ennek a
modszernek. Mert jol atgondolt, mert sok eshetosegre tekintettel van, mert
egyszeruve teszi meg a cross-platform forditasokat is, es egy gcc vagy
eppen libc upgrade sem jelent szinte semmilyen feltuno dolgot. Mert nagy
fegyelemrol tanuskodik a fejlesztok reszerol, mert nem csak azt kell
ellenorizniuk, hogy a most berakott patch lefordul-e, hanem, hogy a make
buildworld is vegigmegy-e vele, ami felfed esetleg nem figyelembe vett
osszefuggeseket is, plane mivel a committerek szabalykonyve szerint ezt egy
ujonnan kicsekkelt tiszta /usr/src-al kell csinalni, hogy az esetleges nem
odatartozo patch-ek ne zavarjak a munkat.

Na most nem allitom, hogy ido szempontjabol mindig ez a legnyerobb
megoldas. Biztosan az, ha pl 4.3-rol 5.0-ra akar valaki frissiteni, mert az
maskent nem is megy, olyan sok minden valtozott kozben. Ha volt egy-egy
nagyobb upgrade, pl a groff frissitese, akkor is egyertelmu nyeremeny. Ha
eppen nem volt, akkor valoban lehet mondani, hogy a perlt mindig ujra
forditani, vagy a gcc-t ketszer ujra forditani felesleges, de ha a valtozas
annyira jelentektelen volt, akkor nem is kell buildworld-ot csinalni
tenyleg. Masreszt az ido relativ: a gep ideje, nem az enyem, mert a
buildworld elinditasa utan nem igenyel operatori jelenletet amig keszen nem
lesz. Es a gep kozben mindvegig multi-user modban mehet, vagyis a
felhasznalok se biztos, hogy sokat eszrevesznek belole. Ezert is van kulon
a make installworld, amihez mar tenyleg le kell menni single-userbe. Ez a
folyamat az en gepemen jelenleg kb 6 orat vesz igenybe, es egyre tobbet, de
nem banom, mert kozben lehet aludni, vagy mint en most, tanulni, es nem
kell a geppel foglalkozni.

Az Open es NetBSD megoldas azert nem olyan igenyes, mert:

1) Az 1) lepes hianyzik. Ez van amikor nem baj, de tul sok mindent
feltetelez, ami nem mindig szerencses. Az pedig egyszeruen nem elegans,
hogy "ha a kernel nem fordul le akkor csinad ezt". Jobb elore gondolkozni.
Nem sok ido de megeri. Es igy nem kell tudnod, hogy mennyi program tartozik
a bootstrap-tools kategoriaba. Te itt mondtal kettot, de mint lattuk sokkal
tobb van es lehet (nem soroltam fel az osszeset) ugyhogy ha FreeBSD-n
kellene tippelgetned, hogy melyik johet szoba, bajban lennel. Es mire arra
pl rajonnel, hogy a config-hez esetleg a yacc is kell, az esetleg egesz
sokaig tartana. Erre az egesz hercehurcara nincs szukseg, automatizalhato,
meg ha annak az aran is, hogy esetleg feleslegesen dolgozott a gep.

2) A cross-tools lepes is hianyzik. Ez rad teszi annak a felelosseget, hogy
csinalj egy cross-compilert ha kell, es mindenkeppen hogy amennyiben kell,
kezzel frissitsd a gcc-t. Az OpenBSD minifaq-ban erre vannak is utasitasok,
de megint minek ezt a felhasznalora bizni? Es plane minek ugy csinalni,
hogy eloszor nezzuk lefordul-e igy aztan ha nem majd berhelunk... neeem
csinaljuk ugy, hogy elsore jo legyen.

3) Az include-k bemasolasa es a make libraries ossze van mosva. Ez
gondokhoz vezethet, ha az include-k nagyon megvaltoznak.

Mint lattuk, ez kozben operatori jelenletet, sot akar beavatkozast igenyel,
ami szinten nem szerencses. Mire felebredek kesz:-)

Ezert pl NetBSD-nel hivatalosan sem ajanljak, hogy mondjuk 1.5.1 rol 1.6-ra
majd igy frissits tehat legkesobb egy-egy uj major release egy binaris
reinstallt jelent altalaban. De OpenBSD-nel is ez a helyzet. Na most ez
ugyan mukodik, es aki nem olyan tapasztalt, hogy kivulrol fel tudja mondani
pl a make world lepeseit:-) annak jobb is, mert kevesebbet ronthat el, de
en nagyon buszke vagyok arra, hogy ezen a gepen reinstall 1999 szeptembere
ota nem volt, akkor is csak azert, mert az akkor meg egyszem lemezt ujra
kellett particionalni. Pedig mindig a legujabb FreeBSD futott rajta. Igy
egyebkent pl az /etc konyvtar is biztonsagban van, igaz, hogy mergemaster
nelkul az elet nehez lenne... ami pl OpenBSD-re mar van, bar meg nincs az
alaprendszerben, de NetBSD-nel nem hallotam rola (amitol meg lehet)

Tehat osszessegeben kijelentheto, hogy ilyen gyonyoru, megbizhato es eros
source upgrade rendszere egyetlen masik OS-nek sincs ma, akar free akar
nem, mert ahol van, ott is inkabb a release engineer hasznalatara van, aki
nem eppen laikus. De ez nem ordongosseg.
Minden mas BSD rendszeren problema nelkul megvalosithato lenne, es
mindegyiknek javara valna. Linuxon egy kicsit nehezebb lenne, de csak hogy
tudjatok rola ott is van egy projekt ami ezt tuzte ki celul.

Nem hiszem, hogy ennek megvalositasaban barmi hatranyos lenne barmelyik
projekt szamara, sot a fegyelem erositesevel meg jot is tesz... egy
fegyelmezett fejleszteshez konnyebb hozzatenni is.

Ez a build rendszer, a mergemaster, a magyar billentyuzet, a konzolos eger,
stb nem nagy dolgok, de nagyban hozzajarulnak ahhoz, hogy az ember
kenyelmesebben hasznalhassa a gepet es maximalisan kihasznalhassa az uj
feljesztesek elonyeit. Ezek nelkul is megy termeszetesen, de milyen lenne,
ha mind a 20 platformon is mukodne ezzel egyutt? Huuuu... annak egyszeruen
nem lenne konkurrenciaja... nekem ez az almom. Mint a Mozilla. Barhol
beteszem es lefordul. Ott is csak elinditom es negy ora mulva visszajovok
es egy uj mozilla var. Jol indul a nap:-)

Udv:
Sz.
-- 
-------------------------------------------------------------------------------
* Adam Szilveszter * JATE Szeged * email: sziszi at petra.hos.u-szeged.hu *
* Honlap : nincs * alternativ email: sziszi at bsd.hu *
* PGP kulcs: Fingereld a sziszi at petra.hos.u-szeged.hu cimet! *
* FreeBSD: tisztabb, szarazabb, biztonsagosabb erzes...! *