Anleitung: Haiku direkt vom Quellcode unter Ubuntu

In der Vergangenheit hatte ich schonmal eine kurze Anleitung geschrieben welche Schritte nötig sind, um Haiku direkt vom Quellcode aus unter Linux zu kompilieren. Leider ist der Artikel mit der haiku-gazette.de Domäne untergegangen.
Nachfolgend also nochmal das Ganze Prozedere zum Bauen von Hybrid-Images (gcc2 und gcc4) unter Ubuntu 10.10 (unter anderen Distributionen sollte es genauso funktionieren, bis auf die Installation der benötigten Tools und vielleicht ein geänderter Verzeichnispfad hier und da).

Um sich die ganze Cross-Kompiliererei, Buildtools und Bereitstellen einer xattr-unterstützenden Partition etc. zu sparen, sollten man sich mal überlegen, ob man nicht lieber direkt unter Haiku Images baut. Da sind schon alle Tools vorhanden und man kann mal locker Punkt 1-4 und 6 dieser Anleitung überspringen...

Alle Infos kann man sich auch bei den offiziellen Guides zusammensuchen. Dort befinden sich auch weitere Details für Leute, die tiefer einsteigen möchten oder spezielle Wünsche berücksichtigen wollen.

UPDATE:
Nachdem das Haiku Projekt von SVN auf GIT gewechselt ist, hab ich das Herunterladen des Sourcecodes aktualisiert.

1. Vorbereitungen

Um beim Imagebau Haikus erweiterte Attribute berücksichtigen zu können, sollte der Quellcode auf einer Partition mit einem Dateisystem liegen, das sogenannte xattr Unterstützung hat. Ich verwende dazu reiserfs, weil ich die Partition dann auch unter Haiku zumindest lesend einhängen kann. Andere geeignete Dateisysteme wären lt. Guide JFS, NTFS (via NTFS-3G), UFS2, XFS, ZFS.

Der Quellcode für die Buildtools ist nach dem Kompilieren etwa 1 GiB groß und das Haiku Verzeichnis inklusive generierter Objekte für gcc2 und gcc4 dann nochmal 3,5 GiB. Den Buildtools Quellcode könnte man zwar theoretisch nach dem Kompilieren wieder löschen, aber wenn sich da was ändert, muss man ihn doch wieder runterladen...
Am besten man stellt gleich eine genügend große Partition zur Verfügung. Mit 10 GiB hat man für die Zukunft keine Sorgen...

Dann folgen noch die Linux-typischen Spielchen, die ich erst durch einige Googelei auf die Reihe gebracht habe.
Es reicht nicht, wie es unter Ubuntu eigentlich bequem geht, die Quellcode-Partition einzuhängen. Man muss dabei den xattr-Support explizit aktivieren. Dazu ist in die Datei /etc/fstab ein entsprechender Eintrag anzuhängen, der die Partition dann entsprechend auch automatisch einhängt:

sudo gedit /etc/fstab

Unter die dort vorhandenen Einträge hängt man die Infos seiner Quellcode-Partition drunter, z.B.:

# <file system>      <mount point>     <type>      <options>           <dump> <pass>
# Sourcecode on /dev/sda11

UUID=1938d3c2-10bb-4945-8150-1b6ec24deae3 /media/Sourcecode reiserfs auto,rw,user_xattr 0 0

Die UUID der Quellcode-Partition bekommt man wie es in der fstab Datei steht (seltsamerweise dort mit Parametern angegeben, die wichtige Infos unterdrücken würden...) durch den Befehl:

blkid

2. Benötigte Tools

Um sicher zu gehen, dass alle benötigten Tools auf dem Linux-System installiert sind, sollte man diesen Befehl in der Konsole starten:

sudo apt-get install git yasm autoconf automake texinfo flex bison gawk build-essential

3. Buildtools Quellcode runterladen

Als nächsten benötigt man unter Linux Cross-Buildtools und eine besondere jam Version. Baut man Haiku unter Haiku, BeOS oder Zeta kann man gleich zu Punkt 5 springen.
Ausgangspunkt ist die oberste Ebene der eingehängten Quellcode Partition. In meinem Fall geschieht das per:

cd /media/Sourcecode

Der Normal-Anwender lädt sich den Quellcode so runter:
git clone git://git.haiku-os.org/buildtools

Der registrierte Entwickler mit Schreibrechten muss beim ersten Mal GIT konfigurieren:

git config --global user.name "Markus Mustermann"
git config --global user.email "markus.mustermann@beispiel.de"

Danach holt sich der registrierte Entwickler den Quellcode per:

git clone ssh://username@git.haiku-os.org/buildtools

4. Buildtools bauen und installieren

Ist der Quellcode auf der Platte, wechselt man zu haiku/buildtools/jam/ kompiliert "jam" und verschiebt das Ergebnis aus bin.linuxx86 nach /usr/bin/

cd haiku/buildtools/jam
make
sudo mv bin.linuxx86/jam /usr/bin/

5. Haiku Quellcode runterladen

Wie für den Buildtools Quellcode, gibt es die Unterschiede zwischen Normal-Anwender und schreibberechtigten Entwickler. Zuerst wechselt man wieder zurück zur obersten Ebene, d.h. direkt auf die Quellcode Partition (hier: cd ../../..).

Normalo:
git clone git://git.haiku-os.org/haiku

Entwickler:
git clone ssh://git.haiku-os.org/haiku

6. Umgebung konfigurieren

Die Optionen zum Konfigurieren der Build-Umgebung sind vielfältig. Hier gehen wir von der Erstellung eines gcc2/4 hybrid Haikus aus und dass der Quellcode auf einem Dateisystem mit xattr-Unterstützung liegt (und dass die Partition auch mit dieser xattr-Unterstützung eingehängt ist...).

Zuerst legen wir zwei Ordner an, in denen das Image gebaut wird; einen für gcc2, einen für gcc4.

cd haiku/haiku/trunk
mkdir generated
mkdir generated-gcc4

Jetzt wechseln wir in die jeweiligen Ordner und konfigurieren das Build-System entsprechend für ein gcc2 Hybrid, bzw. gcc4 Hybrid.

cd generated
../configure --use-xattr --distro-compatibility official --include-gpl-addons --include-patented-code \
--build-cross-tools ../../../buildtools --alternative-gcc-output-dir ../generated-gcc4

cd ../generated-gcc4
../configure --use-xattr --distro-compatibility official --include-gpl-addons --include-patented-code \
--build-cross-tools-gcc4 x86 ../../../buildtools --alternative-gcc-output-dir ../generated

7. UserBuildConfig

Unter haiku/haiku/trunk/build/jam/ befinden sich eine Menge Konfigurationsdateien, darunter auch die UserBuildConfig (diese wird am besten aus einer Kopie von UserBuildConfig.sample erstellt). Mit ihr lassen sich Build-Profile erstellen, um z.B. automatisch verschiedene Software aus OptionalPackages in das Image zu packen oder um direkt auf eine Partition zu schreiben oder ein Image für USB/CD oder VMWare/VirtualBox zu erstellen. Außerdem lassen sich durch eine Reihe Befehle externe Dateien in das Image kopieren oder auch entpacken (man denke an Backups von gezippten config-Ordnern etc.)

Hier also eine komplette UserBuildConfig mit drei Profilen:

• @VM erzeugt ein Image für VMWare/VirtualBox.
• @ANY erzeugt ein anyboot-Image für USB-Sticks oder zum Brennen auf CD.
• @HD installiert direkt auf eine Partition (unbedingt dreimal checken, dass man auch die richtige beschreibt!!).

# Für OpenSSH muss diese Variable auf irgendeinen Namen gesetzt werden
HAIKU_IMAGE_HOST_NAME = "Walter" ;

# Setzen der deutschen Keymap
AddFilesToHaikuImage home config settings : <keymap>German 
 : Key_map ;

# HAIKU_TOP ist immer die haiku/trunk/ Ebene
# Dort habe ich den Ordner "user_data" angelegt und QuickLaunch.zip reingelegt.
# Die wird nach /boot/apps/ entpackt.
ExtractArchiveToHaikuImage apps
 : $(HAIKU_TOP)/user_data/QuickLaunch.zip ;

# Kopiert den "artwork" Ordner ohne die .svn Dateien nach /boot/home/
CopyDirectoryToHaikuImage home
 : $(HAIKU_TOP)/data/artwork : : -x .svn ;

# Für ein Hybrid Image werden die Bibliotheken für den alternativen Kompiler benötigt
HAIKU_ADD_ALTERNATIVE_GCC_LIBS = 1 ;

# In manchen Ländern durch Softwarepatente geschützter Code wird benutzt
HAIKU_INCLUDE_PATENTED_CODE = 1 ;

# GPL-lizensierte Add-ons werden dazugepackt
HAIKU_INCLUDE_GPL_ADDONS = 1 ;

# Alle Build-Profile sollen diese OptionalPackages erhalten
AddOptionalHaikuImagePackages BePDF ;
AddOptionalHaikuImagePackages OpenSSL ;
AddOptionalHaikuImagePackages OpenSSH ;
AddOptionalHaikuImagePackages Pe ;
AddOptionalHaikuImagePackages Vision ;
AddOptionalHaikuImagePackages WebPositive ;
AddOptionalHaikuImagePackages WifiFirmwareScriptData ;
AddOptionalHaikuImagePackages wpa_supplicant ;
AddOptionalHaikuImagePackages XZ-Utils ;

# Build-Profil 1: Basiert auf dem Profil "disk", installiert auf eine Partition
# Natürlich mit dem Pfad zur richtigen Partition anstatt "/dev/sda77"!
DefineBuildProfile HD : disk : "/dev/sda77" ;

# Build-Profil 2: Basiert auf dem Profil "anyboot-image"
DefineBuildProfile ANY : anyboot-image : "haiku-anyboot.image" ;

# Build-Profil 3: Basiert auf dem Profil "vmware-image"
DefineBuildProfile VM : vmware-image ;

switch $(HAIKU_BUILD_PROFILE) {
 case "HD" : {
  # Zusätzlich zu den obigen OptionalPackages für alle Profile:
  AddOptionalHaikuImagePackages ArmyKnife ;
  AddOptionalHaikuImagePackages BeBook ;
  AddOptionalHaikuImagePackages BeZillaBrowser ;
  AddOptionalHaikuImagePackages Clockwerk ;
  AddOptionalHaikuImagePackages Development ;
  AddOptionalHaikuImagePackages Paladin ;
  AddOptionalHaikuImagePackages Subversion ;
  AddOptionalHaikuImagePackages TimGMSoundFont ;
  AddOptionalHaikuImagePackages Welcome ;
  AddOptionalHaikuImagePackages WonderBrush ;
 }

 case "ANY" : {
  # Größe des Images in MiB
  HAIKU_IMAGE_SIZE = 900 ;
  # Zusätzlich zu den obigen OptionalPackages für alle Profile:
  AddOptionalHaikuImagePackages ArmyKnife ;
  AddOptionalHaikuImagePackages BeBook ;
  AddOptionalHaikuImagePackages BeZillaBrowser ;
  AddOptionalHaikuImagePackages Clockwerk ;
  AddOptionalHaikuImagePackages Development ;
  AddOptionalHaikuImagePackages Paladin ;
  AddOptionalHaikuImagePackages Subversion ;
  AddOptionalHaikuImagePackages TimGMSoundFont ;
  AddOptionalHaikuImagePackages Welcome ;
  AddOptionalHaikuImagePackages WonderBrush ;
 }

 case "VM" : {
  # Größe des Images in MiB
  HAIKU_IMAGE_SIZE = 900 ;
 }
}

Weitere Infos stehen in UserBuildConfig.sample und UserBuildConfig.ReadMe. In OptionalPackages sind alle verfügbaren optionalen Softwarepakete zu finden.
Die meisten dieser Pakete lassen sich auch noch nachträglich unter Haiku installieren. Um eine Liste aller verfügbaren Pakete zu bekommen, schreibt man im Terminal:

installoptionalpackage -l

Um eines zu installieren, einfach dessen Namen anstatt des -l angeben. Eine Option zum automatischen Deinstallieren gibt es allerdings nicht.

8. Komplettes Haiku Image bauen

Alle obigen Punkte muss man natürlich nur einmal durchführen. Hat man sein Build-System einmal am Laufen, führt man einfach nur diesen Punkt 8 aus, wenn man ein aktuelles Haiku Image haben möchte.

Um den kompletten Quellcode zu aktualisieren und evtl. eigene Änderungen oben drauf zu legen:

cd haiku
git pull --rebase

Soll nur eine bestimmte Komponente aktualisiert werden, wechselt man in den entsprechenden Ordner, dann wird nur dieser und alle Unterverzeichnisse auf Stand gebracht, z.B. src/apps/ für alle Anwendungen. Setzen deren Änderungen jedoch ebenfalls geänderte Subsysteme voraus (z.B. Änderungen beim Layout oder Locale Kit), wird die Kompilierung natürlich schief gehen und man kommt nicht drumrum auch den Rest des Quellcodes zu aktualisieren...

Um dann das Image zu bauen:

cd generated
jam -qj2 @ANY

So wird ein gcc2-hybrid Image gebaut. Möchte man ein gcc4-hybrid Image, wechselt man stattdessen nach generated-gcc4/ bevor man jammed.
Das -q bedeutet, das jam sofort abbricht wenn es auf einen Fehler stößt.
Das -j2 lässt 2 Threads simultan jammen. Am effektivsten setzt man die Zahl der Threads auf die Anzahl an Cores der CPU.
Das @ANY wählt ein Build-Profil aus, hier das anyboot-Image aus unserer UserBuildConfig. Neben diesen selbst-definierten Profilen gibt es auch noch offizielle, z.B. alpha-* oder nightly-* (s. ReleaseBuildProfiles).

9. Image installieren

Installiert man nicht direkt auf eine Partition (unser @HD Profil), befindet sich am Ende ein Image im generated Ordner, das sich entweder als Image für VMWare/VirtualBox verwenden lässt oder im Falle eines anyboot-Images auf CD brennen oder USB-Stick schreiben lässt.

Für den USB-Stick geschieht das mit:

dd if=haiku-anyboot.image of=/dev/sdb bs=1M

Als of (Output file) muss man natürlich den richtigen Pfad zu seinem USB-Stick wählen. Hier ist also auch wieder Vorsicht angesagt!

Vom USB-Stick kann man dann Booten und den neuen Build ausprobieren oder wie üblich auf eine Partition installieren.

10. Tipps & Tricks

• Wird das jammen aus irgendeinem Grund abgebrochen, und es liegt kein bekanntes Problem vor (s. entsprechende Meldungen auf der Dev Mailingliste oder suche nach aktuellen "[BOM]" (Build-O-Matic) Meldungen auf der Commits Mailingliste), sollte man am besten den objects Ordner in den generated Verzeichnissen löschen. Anschließend jammed man mit dem zusätzlichen Parameter -a, also jam -qaj2 @....
  Bei manchen seltsamen Fehlern soll auch ein Neustart helfen. Klingt komisch, ist aber so...

• Immer eine gute Anlaufstelle wenn man auf Probleme stößt: IRC (#haiku und ggf. #haiku-de bei irc.freenode.net). Möchte man den anderen längere Fehlermeldungen oder seine UserBuildConfig zeigen, sind Dienste wie Pastebin oder für Bilder Imagepin zu empfehlen.

• Um den Quellcode auf eine konkrete Revision zu bringen benutzt man den Befehl git checkout {Revisionsnummer}. Hängt man noch einen Pfad/Dateinamen an, wird nur diese Datei auf diese Revision gebracht.

• Man muss nicht immer gleich ein ganzes Image bauen, will man nur eine Komponente aktualisieren. Im generated Ordner gibt man dazu einfach jam -qj2 {Komponente} ein, also z.B. jam -qj2 ShowImage oder jam -qj2 net_server. Die aktualisierte Komponente befindet sich dann (etwas versteckt) im entsprechenden Verzeichnis unter generated/objects/.
  
  Noch einfacher geht es mit dem @HD Build-Profil. Hier wird die Komponente automatisch in der Haiku Partition installiert. Dazu schreibt man einfach jam -qj2 @HD update {Komponente}.
  Bei kritischen Komponenten muss man natürlich Vorsicht walten lassen. Installiert man so einen fehlerhaften app_server, kann man u.U. Haiku nicht mehr starten...

• Will man auf Daten von seiner Haiku Partition von Linux aus zugreifen möchte, geht das zumindest lesend, indem man die entsprechende Partition ("sdXxx" entsprechend anpassen) einhängt:
  sudo mount /dev/sdXxx /media/Haiku -t befs.
  
  Neuere Ubuntu Versionen erkennen BFS-Partitionen automatisch. Siehe dazu auch den Beitrag in Idefix' Blog