CyanogenMod für Nexus 4 (mako) auf Debian oder Ubuntu (x64) kompilieren

  • 100 Antworten
  • Letztes Antwortdatum
Echter Linux Rechner, 4 Kerne, 8GB RAM, System und Repo auf SSD, 14 Minuten :D
 
An, aber immernoch mit max. 900mb.

Gesendet mit Tapatalk 2
 
Kannst Du den nicht mal auf 5GB erhöhen? Bei mir bringt das eine Einsparung von ca. 50%.
 
Ja, mach ich beim nächsten Build. Morgen oder so. Mal sehn.

Gesendet mit Tapatalk 2
 
Boa :D

Könnt ihr während des Bauens mal

Code: 
ps aux | grep -i "make -j"

ausführen und mir sagen, ob ihr auch mit "make -j2 bacon" baut? Oder eventuell mehr Jobs (-j)...

Mit einer SSD kannst für ein Android Build bestimmt 4 Jobs nehmen, was nochmal gut was bringen sollte. :) Bei einer HDD wäre es evtl. sogar langsamer, die muss sich ja ständig neu ausrichten. Weiß auf Anhieb aber nicht, wo man das genau definieren kann für CM. Aber 14 Minuten ist ja schon wenig. :D
 
Code: 
make -j8 bacon
 
  • Danke
Reaktionen: andry
Danke, dann wird das also entsprechend der Cores variabel angepasst. :)
 
Code: 
Package complete: /home/schubi/Projekte/CM10.1/out/target/product/mako/cm-10.1-20130114-UNOFFICIAL-mako.zip
md5: e1e190b7d58bb87279ceab2ec0def9ed

real	8m55.022s
user	23m48.509s
sys	0m46.671s
CCACHE -s:
Code: 
cache directory                     /home/schubi/.ccache
cache hit (direct)                     0
cache hit (preprocessed)           21121
cache miss                         76202
called for link                     7690
compile failed                         2
preprocessor error                     2
unsupported source language        12661
unsupported compiler option          757
no input file                       3291
files in cache                     38498
cache size                           4.4 Gbytes
max cache size                       5.0 Gbytes
 
  • Danke
Reaktionen: Jensemann1969
Das ist ja schon ziemlich "raketig"! :thumbup:
 
Jup, dafür ist die 64GB SSD jetzt mit Ubuntu, Repository und CCache bis auf 1GB voll. Muss entweder was größeres her oder das Repo doch wieder auf die HDD.

Könnte mir gut vorstellen, dass es warscheinlich nichtmal nur die SSD ist, die das ganze so beschleunigt sondern auch die für die SSD gesetzte mount-option noatime. Kannste ja evtl. mal testen.
 
Zuletzt bearbeitet:
Das mit der atime ist ne coole Idee, muss ich mal testen. Aber vorher eine kleine Partition dafür bauen, da ich die atime sonst eigentlich brauche...
 
Klein? Bei mir ist das Repository 40GB groß *g*
Aber apropos: wie macht man das eigentlich am besten das komplette repo zu verschieben? Ich hab das momentan so "gelöst", dass ich mit mount --bind den original Ordner wiederherstelle.

Gesendet mit Tapatalk 2
 
Der_Schubi schrieb:
Jup, dafür ist die 64GB SSD jetzt mit Ubuntu, Repository und CCache bis auf 1GB voll. Muss entweder was größeres her oder das Repo doch wieder auf die HDD.

Könnte mir gut vorstellen, dass es warscheinlich nichtmal nur die SSD ist, die das ganze so beschleunigt sondern auch die für die SSD gesetzte mount-option noatime. Kannste ja evtl. mal testen.
Zum Vergrößern anklicken....


Die mount-Option noatime habe ich eben mal getestet. Das macht bei mir keinen Unterschied.
 
Ok, war einen Versuch wert. Hätte gedacht das macht was aus.
Nebenbei: habt ihr eigentlich den fs miner tracker dingens laufen? Ich hab den lahmgelegt weil er nach dem Kompilieren mit 5GB im RAM liegt.

Gesendet mit Tapatalk 2
 
Der_Schubi schrieb:
Ok, war einen Versuch wert. Hätte gedacht das macht was aus.
Nebenbei: habt ihr eigentlich den fs miner tracker dingens laufen? Ich hab den lahmgelegt weil er nach dem Kompilieren mit 5GB im RAM liegt.

Gesendet mit Tapatalk 2
Zum Vergrößern anklicken....

Was ist denn das? fs miner tracker? Gibt es bei mir nicht.

Kurz zur mount-Option: Da ich in einer VM arbeite, kann es sein, dass die Option bei mir nichts bringt. Das müsstest Du aber mal selbst auf Deinem echten Linux mit und ohne Parameter probieren.
 
Unter anderem der Prozess tracker-miner-fs. Ist der Filesystem Tracker von Debian/Ubuntu. Stichwort Zeitgeist. Gib mal "tracker-control --status" ein.
Wie gesagt, bei mir liegt er nach dem Kompilieren mit 5GB im RAM.

Zu noatime: Nutzt du eine echte Partition für die VM oder ein Image-File? Bei nem Image würde noatime wohl nicht mehr ins Gewicht fallen.
 
Der_Schubi schrieb:
Aber apropos: wie macht man das eigentlich am besten das komplette repo zu verschieben? Ich hab das momentan so "gelöst", dass ich mit mount --bind den original Ordner wiederherstelle.
Zum Vergrößern anklicken....

rsync -av original neu

z.B. (original: ~/CM10.1/system , neu: ~/backup/CM10.1/system):

Code: 
cd ~/CM10.1/ && rsync -av system ~/backup/CM10.1/
 
  • Danke
Reaktionen: Jensemann1969
Nein, das funktioniert nicht. Zumindest nicht wenn ich an der neuen Position auf das Repository zugreifen will. Irgendwo im repo-ordner oder so sind da die Pfade gespeichert, oder?

Gesendet mit Tapatalk 2
 
Kann sein, das es in Deinem Fall so nicht funktioniert, ich benutze den "neuen" Ordner nur für meine Sourcecode Änderungen, und zum Kompilieren,
der "originale" Ordner ist nur zum repo syncen. (Ich mache also kein repo sync vom "neuen" Ordner aus).

Edit:

repo sync funktioniert auch von der neuen Position aus
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten