A dev.tree és a fordítási hibák

Ha körülnézünk a forrásban és nem csak letöltöttük, akkor láthatjuk, hogy az összes eszköz ugyan abból a forrásból épül fel. Ehhez arra van szükség, hogy a fordító minden csomagban előre tudja melyik kódúton haladhat éppen. Pontosan ezt a célt szolgálja a dev.tree.

Az egyedi kódunk a

devices/gyarto/eszkoz

...útvonalon találjuk meg.

Itt lapul az eszközünk kódja

Ha megvizsgáljuk láthatjuk, hogy jórészt make (*.mk) fájlokból áll. Ezek egy meghatározott szoros hierarchia szerint követik egymást, amivel jobb nem vacakolni, mert nagyon bele lehet keveredni. Beszédes nevük van ám mégsem kötött a tartalmuk, csak formalitásból vannak ilyen sorrendben és név szerint.

Készül a boardconfig.mk. Reményteli pillanatok ezek, mikor még azt hisszük működik is.

Fontosabb nekünk, ami mellettük van, főként ha lib* mappákat látunk. Ezekben a mappákban ugyanis az eszközünk egyedi kódjai lapulnak, amiket a megfelelő kapcsolóval az előbbi make fájlokban le fogunk fordítani a folyamat alatt.

Amiről viszont a legtöbb modder álmodozik, az az overlay mappa. Hogy miért? Mert amit ide rakunk, mintegy tükörképét létrehozva a külső forrásnak, azzal nemes egyszerűséggel "felülírja" a meglévő forrás részeket. Az idézőjel nem véletlen, ugyanis a "felülírás" nem fájlszinten történik, hanem soronként. Képek esetében egy az egyben kicseréli őket. Máris kész az egyedi grafika! Csak ide kell pakolni mindent és minden romunk egyedi lesz!

Reklámszagúnak tűnik az utolsó két mondat? Igen, mert az is! Ugyanis sajnos vagy sem, a legtöbb "modder" kb. ennyit tud megoldani saját kútfőből, semmivel sem többet.

Ide tartozik még a kernel mappa, amiben a kernel forrása van, vagy a lefordított kernel bináris (bzImage, vagy zImage). Ha szerencsénk van külön nem kell vele foglalkoznunk, ha nem, akkor valószínűleg nem ezt a cikket olvasgatjuk.

Megtalálható itt még a kibontott ramdisk és a recovery mappa is, amelyek a nevükhöz méltó tartalommal bírnak.

Na de mi van akkor, ha a forrásunkba még nem nyúltunk bele egyáltalán, de máris nem fordul le valami miatt? Hát igen: gáz. Ilyenkor ugyanis a fordító szép hosszú hibaüzenettel "szórakoztat" bennünket, mi pedig megtanuljuk az első programnyelvet, amit minden kezdő programozó megtanul: a káromkodást.

Merthogy a CM csapat is hibázik és nem is egyszer forul elő, hogy bizony bekerül egy kis homok a gépezetbe.

Mit tehetünk?

A hibaüzenet alapján azonosíthatjuk, hogy melyik forrásrészünk nem akaródzik lefordulni. Vegyünk egy egyszerű példát:

Azt mondja a fordítónk, hogy márpedig a bionic/libc/stdio/fflush.c fájlt nem lehet lefordítani. Lássuk mi lehet a gond!

Ehhez menjünk el szépen a bionic mappáig:

$ cd bionic

Majd adjuk ki a:

$ git log

...parancsot.

Egy listát látunk, amiben dátum szerint fel vannak sorolva a legutóbbi módosítások. Jusson eszünkbe máris, hogy a CM romok gyakran fordulnak le a szerveren is. Tehát jó esélye van annak, hogy ha van előző kiadott build, akkor az még jó volt.

Nézzük meg az utóbbi módosításokat. Mellette ott van a commit sorszáma és a készítő.

Most pedig ezzel a számmal (dupla katt, jobb klikk-el másolható), szépen fáradjunk el ide.

A Gerrit, az Android online verziókövetője

A fenti kereső elfogadja ezt a számot normális esetben. (Nem normális esetek is vannak sajnos mostanában).

Ha megvan a módosítás, akkor lehet agyalni, hogy vajon mit rontottak el. Illetve vissza is vonhatjuk az egészet:

Ehhez keressük meg a csomagunk: itt.

Majd kattintsunk a fenti "Commits" fülre és keressük meg az ominózus bejegyzést. rákattintva lesz egy olyan rész közvetlen a commit alatt, hogy "Parent", mellette pedig egy szám. Ezt jegyezzük meg!

A Settings csomag commit ága

Adjunk egy ilyen parancsot a Terminalban:

git reset --hard aparentmellettiszám

Ha minden jól ment, akkor a:

HEAD is now at sorszam commit

...feliratot látjuk és a forrásunk a korábbi remélhetőleg működő verzióra áll vissza.

A cikk még nem ért véget, kérlek, lapozz!