Firefox, Thunderbird u. a. Mozilla-Apps selbst erstellen

  • Autor
  • Nachricht

polysom

Offline

Benutzeravatar


  • Wohnort: Dresden
1  Do Dez 24, 2009 13:44
letzte Änderungen: 10.10.2010


Kapitel:

I. Vorbereitungen
II. Erste Schritte: Den Quellcode für ein Release-Build holen & die mozconfig
III. Ein Release-Build erstellen
IV. Ein Trunk-Build erstellen
V. Das Programm als Universal Binarie erstellen
VI. Den Build optimieren, Performance-Steigerung
VII.Tipps zur Fehlersuche & Debugging
VIII. Profile-Guided Optimization (PGO)
IX. Eine 64bit Executable erstellen
X. Grand Central Dispatch
XI. Lightning (Kalender)
XII. Enigmail
XIII. Einen Fehler an Mozilla melden (Bugzilla)
XIV. Anhang 1 (Nützliches, Tipps & Tricks)
XIV. Anhang 2 (user.js, UserChrome.css und UserContent.css)


Dies ist eine kleine Einführung in Mozilla-Programme und wie man sich diese Programme anpassen kann. Die am häufigsten verwendeten Mozilla-Produkte dürften wohl Firefox, Thunderbird und Camino sein. Speziell für Thunderbird (aber auch andere Email-Clients) gibt es hier eine List mit den besten (vom ISP empfohlenen) Einstellungen: http://ispdb.mozillamessaging.com/list

Bezüglich der unterschiedlichen Einstellungsmöglichkeiten siehe hier.
Achtung: Verwendet man eine alte Version von Thunderbird sollte dort die Option "TLS, wenn möglich" unter gar keinen Umständen gewählt werden, weshalb nicht, siehe hier!! In Thunderbird 3.0 wurde diese Option daher ab Version 3.0 Beta 2 entfernt.

Um Mozilla-Programme anzupassen gibt es mehrere Möglichkeiten:
1. Man installiert Add-Ons für Firefox oder Thunderbird um das Aussehen oder die Funktionalität zu verändern.
2. Man baut sich seine eigene user.js, UserChrome.css und/oder UserContent.css (mehr dazu siehe VIII. Anhang 2, ganz unten).
3. Oder man baut sich sein Programm von Grund auf selber zusammen. Darum soll es in diesem Tutorial auch zum Großteil gehn.
Natürlich können alle 3 Punkte beliebig kombiniert werden.


Für den täglichen Gebrauch gibt es die Programme von Mozilla auf den entsprechenden offiziellen Seiten als Download. Wer sein Programm individuell anpassen möchte kann sich sein Programm mit eigenen Vorgaben auch selber bauen. Dies geht dann an die Wurzel des Programms und greift tiefer ein als z.B. das Installieren von Plug-Ins, Themes (Skins) oder sonstigen Add-ons. Das gute an Open Source ist, dass von jedem Projekt der Quellcode öffentlich zugänglich ist. Dieser wird hierfür benötigt.

Vor dem Experimentieren sollte man zur Sicherheit ein Backup von seinem Thunderbird- bzw. Firefox-Ordner erstellen (zu finden unter /User/Library)!
Dies kann man z.B. recht einfach machen indem man den Ordner über das Finder-Kontextmenü zippt (... komprimieren).
Dieser Hinweis soll nicht zur Abschreckung, sondern nur zur Absicherung dienen. Das Schlimmste was mir bisher passiert ist, war dass ich meinen Thunderbird-Papierkorb nicht mehr entleeren konnte bzw. die Applikation beim Start abgeschmiert ist. Dies ließ sich aber relativ leicht beheben.

Hier nun eine Anleitung wie man sich sein eigenes Mozilla-Programm mit Hilfe des Quellcodes erstellen kann. Da ich mir auf diese Weise Thunderbird erstellt habe geht diese Anleitung auch verstärkt auf Thunderbird ein. Jedes andere Programm der Mozilla Foundation (Firefox, Thunderbird, SeaMonkey, Bugzilla, Camino, Sunbird, Minimo) lässt sich selbstverständlich genau so erstellen.
Man sollte sich dafür sehr viel Zeit nehmen. :kaffee:
Also erst mal alles in Ruhe lesen, sich Gedanken machen und dann kann es mit dem Experimentieren los gehen. :)

Bevor man los legt, sollte man sich auch über einige prinzipielle Dinge im Klaren sein. Dazu gehört zum Beispiel der Unterschied zwischen "Trunk" und "Branch". Dies wird z.B. hier und hier gut erklärt.




I. Vorbereitungen

Zuerst benötigt man einige Grundlagen (und genügend Platz auf der Festplatte!).
• Es müssen auf jeden Fall die Apple Developer Tools (XCode bzw. iPhone SDK) installiert werden. Mindestens ist XCode 2.5 erforderlich, ich bevorzuge das iPhone SDK. Will man die Applikation als Universal Binarie erstellen benötigt man mindestens das MacOSX10.4u.sdk (ab Gecko 2.0 mind. MacOSX10.5.sdk und für 64bit mind. MacOSX10.6.sdk).
• Des weiteren benötigt man noch ein paar Bibliotheken. Recht einfach lassen sich diese mit MacPorts oder Fink installieren. Da das Installieren von Fink unter Leopard als ich damit angefangen habe noch etwas knifflig war, habe ich es mit MacPorts gemacht. Daher beschreibe ich hier die Vorgehensweise mit MacPorts. Wie das mit Fink geht ist dem weiterführenden Link zu entnehmen.
Zuerst installiert man MacPorts mit Hilfe des OS X - spezifischen Binaries.
Da bei mir noch keine .profile vorhanden war hat mir MacPorts einen Installationsfehler gemeldet. Ich hab mir dann selbst in meinem User-Verzeichnis eine Datei .profile mit dem Inhalt
export PATH=/opt/local/bin:/opt/local/sbin:$PATH

erstellt (danach Ab- und wieder Anmelden nicht vergessen).

:idee: Wer sich daran stört dass der von MacPorts installierte Ordner sichtbar ist, kann diesen auch unsichtbar machen mit:
$ sudo chflags hidden /opt

Dann startet man das Terminal, aktualisiert MacPorts und installiert alles was benötigt wird via MacPorts. Dazu gibt man nacheinander folgendes ins Terminal ein:

$ sudo port -v selfupdate
$ sudo port install libidl
$ sudo port install autoconf213
$ sudo port install mercurial

Ab Gecko 2.0 noch:
$ sudo port install yasm

optional (für Enigmail):
$ sudo port install gnupg2

:idee: Das Aktualisieren der Pakete (sollte eine neuere Version erschienen sein) geht dann mit sudo port upgrade outdated, deinstallieren eines Paketes mit sudo port uninstall Paketname, das Anzeigen aller installierter Ports mit port installed. Beim Aktualisieren der Pakete bleiben gelegentlich alte Installationen zurück, dies lässt sich aufräumen mit sudo port -f uninstall inactive.
Standardmäßig wird die Ausführdatei nur in einer Architektur erstellt (unter 10.5 als i386 und unter 10.6 als x86_64). Will man das Binarie in mehreren Architekturen installieren muss man zuvor die MacPorts-Konfigurationsdatei /opt/local/et c/macports/macports.conf ändern. Unter universal_archs sind die Architekturen angegeben die gebaut werden sollen, möglich sind ppc, i386, ppc64 und x86_64. Im Terminal wird dann einfach nur immer ein +universal an den Befehl gehängt, z.B. für libidl $ sudo port install libidl +universal (manche Pakete sind aber z.B. noch nicht 64bit-fähig). Ein anderer Compiler (z.B. gcc-4.2) lässt sich wählen mit $ sudo port install <portname> configure.compiler=gcc-4.2. Mehr dazu siehe hier und hier.


Damit wären die Vorbereitungen abgeschlossen und man kann sich an die Arbeit machen sein Programm zu basteln. Für Camino sind noch weitere Dinge erforderlich (siehe dazu im weiterführenden Link).

Die Developer Tools benötigen ca. 3 GB, der Projekt-Ordner (bei mir "temp") bis zu 2,5 GB und der Ordner "opt" von MacPorts erreicht (solange nicht noch andere Dinge installiert sind) ungefähr 150-250 MB.

Weiterführende Links: http://developer.mozilla.org/en/docs/Ma ... requisites
http://wiki.mozilla.org/Mac:Build_Requirements
https://wiki.mozilla.org/index.php?titl ... 2FMac-10.5
http://guide.macports.org/
http://developer.apple.com/mac/articles ... ports.html
http://developer.apple.com/tools/gcc_overview.html



II. rste Schritte: Den Quellcode für ein Release-Build holen & die mozconfig

Nun erstellt man sich zuerst ein Verzeichnis "temp" .

$ mkdir /temp

Und holt sich dann den Quellcode der aktuellen Version (Release) und entpackt diesen im eben erstellten Verzeichnis "temp". Nun sollte man einen Ordner "mozilla" (/temp/mozilla) oder "src" haben.
Firefox: http://releases.mozilla.org/pub/mozilla ... st/source/
Thunderbird: http://releases.mozilla.org/pub/mozilla ... st/source/
Camino: http://ftp.mozilla.org/pub/mozilla.org/camino/source/
SeaMonkey: http://releases.mozilla.org/pub/mozilla ... /releases/

Danach wechselt man in das Verzeichnis
$ cd /temp/mozilla

und erstellt dort eine Datei mit dem Namen “.mozconfig”. (der Punkt vorne ist wichtig!). Diese Datei ist sehr wichtig und legt bestimmte Eigenschaften des späteren Programms oder Kompilierungsoptionen fest. Das geht im Terminal mit $ sudo pico .mozconfig. Editieren kann man die mozconfig auch gut mit Smultron (Fraise) o.ä. Die mozconfig kann bei jedem anders aussehen. Setzt man eine Raute (#) vor eine Zeile in der mozconfig wird diese Option deaktiviert.
Beispiel (für Thunderbird 3.1 in deutsch):

CC=gcc-4.2
CXX=g++-4.2

# Options for client.mk.
mk_add_options MOZ_MAKE_FLAGS=-j4
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options MOZ_CO_LOCALES=de
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
mk_add_options AUTOCONF=autoconf213

# Options for 'configure' (same as command-line options).
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
ac_add_options --enable-application=mail
ac_add_options --enable-optimize
ac_add_options --enable-static
ac_add_options --enable-update-packaging
ac_add_options --enable-update-channel=release
ac_add_options --enable-official-branding
ac_add_options --enable-ui-locale=de
ac_add_options --with-l10n-base=/temp/src
ac_add_options --disable-shared
ac_add_options --disable-debug
ac_add_options --disable-tests

Hinweis: Da in dieser mozconfig das offizielle Branding aktiviert ist, darf so ein Build nach Mozilla Foundation Trademark Policy nur für den Eigengebrauch verwendet werden, will man seinen Build verteilen muss man dies deaktivieren (die entsprechenden Zeilen löschen und/oder ein # vor die Zeile setzen).
Für diese deutsche Version muss man sich natürlich noch die Lokalisierungs-Dateien besorgen und unter /temp/src in einem Ordner "de" speichern.
Für Gecko 1.9.1: http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/de/
Für Gecko 1.9.2: http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/de/

-------------------------------

Erklärung einiger Konfigurationsoptionen

mk_add_options MOZ_CO_LOCALES=de und ac_add_options --enable-ui-locale=de
Gibt vor in welcher Sprache Thunderbird erstellt werden soll. "de" steht hier für eine deutsche Version. Lässt man diese 2 Attribute weg entsteht eine US-Version. Die zur Verfügung stehenden Sprachen sind der Datei /mozilla/toolkit/locales/en-US/chrome/global/languageNames.properties zu entnehmen.

CC=gcc-4.2 und CXX=g++-4.2
Variablen für den Compiler, stellt hier sicher dass die GCC-Version 4.2.x verwendet wird. Mit älteren Versionen als 4.0 ist es unter Umständen nicht möglich Thunderbird als Universal Binarie zu bauen. Der Funktionsumfang der GCC 4.2 von Apple unterscheidet sich von dem der offiziellen 4.2. Evtl. sollte dann aber noch die Universal-mozconfig auf die dort vorgegebene GCC-Version überprüft werden.
Es existieren folgende Variablen für Preprozessor und Compiler (wobei in einer mozconfig meist nur CC, CXX, CFLAGS und CXXFLAGS verwendet werden):
CC = C-Compiler
CXX = C++-Compiler
CPP = C-Preprozessor
CXXCPP = C++-Preprozessor
LD = Compiler für Linker
F77 = Fortran77-Compiler
FC oder F90 = Fortran90-Compiler
CFLAGS = Debugging und Optimierungs-Flags für den C-Compiler
CXXFLAGS = Debugging und Optimierungs-Flags für den C++-Compiler
CPPFLAGS = C++-Preprozessor-Flags
LDFLAGS = Flags für den Linker
FFLAGS = Debugging und Optimierungs-Flags für den Fortran77-Compiler
FCFLAGS = Debugging und Optimierungs-Flags für den Fortran90-Compiler

Zum Kompilieren mit Apples llvm-gcc-4.2 verwendet man hier:
CC="llvm-gcc-4.2"
CXX="llvm-g++-4.2"

und zum Kompilieren mit Clang:
CC="clang"
CXX="clang++"


. $topsrcdir/mail/config/mozconfig
Gab früher an wo das Standard-mozconfig-File liegt und wurde unter comm-central/mozilla-central abgeschafft (außer man erstellt ein UB). Für Firefox ersetzt man natürlich "mail" gegen "browser".

ac_add_options --enable-application=mail
Gibt an was man eigentlich basteln möchte. "mail" für Thunderbird, "browser" für Firefox, "calendar" für Sunbird, "suite" für SeaMonkey, "camino" für Camino usw.

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
Gibt an dass mit einer so genannten "objdir" gearbeitet werden soll. Es entsteht dann zum Beispiel ein Ordner mozilla/obj-powerpc-apple-darwin8.11.0/ in den alle Codes und Objekte geladen werden. So können sich die Quellcodes nicht vermischen. Die Verwendung einer obdir wird zwingend angeraten!

ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
Gibt an welches SDK verwendet werden soll. Um ein Universal Binarie zu machen benötigt man mindestens 10.4u. Will man sein Programm für Snow Leopard optimieren setzt man hier MacOSX10.6.sdk ein.

ac_add_options --enable-macos-target=10.5
Gibt die minimale Systemversion vor mit der das Programm läuft, hier Leopard. Standardmäßig (würde man die Zeile weg lassen), wäre es 10.5 für Trunk-Builds und 10.4 für Gecko 1.9.1.

ac_add_options --with-pthreads
Hiermit kann man die Pthreads aktivieren. Dies ist ein optionaler Teil von POSIX.

ac_add_options --enable-optimize
Hiermit kann man sein Build optimieren. Es können so auch Optimierungen für bestimmte Architekturen erzeugt werden. Wird dies weg gelassen wird nicht optimiert. -O1 optimiert ein wenig, -O2 optimiert ein wenig mehr und -O3 optimiert stark. Weitere Informationen hierzu findet man in Kapitel VI. "Den Build optimieren, Performance-Steigerung". Die im Internet kursierenden auf G4, G5, Intel optimierten Builds von Firefox sind auch auf diese Weise hergestellt worden.
Da hierdurch aber moduleigene Optimierungsoptionen (MODULE_OPTIMIZE_FLAGS) überschrieben werden ist es besser zur Optimierung CFLAGS und CXXFLAGS zu verwenden (siehe ebenfalls Kapitel VI.).
Etwas mehr über spezifische Optimierungen findet man auch hier:
http://developer.apple.com/documentatio ... tions.html
http://www.gentoo-wiki.com/Safe_Cflags
http://www.spec.org/cpu2006/flags/CPU2006_flags.html
http://www.intel.com/software/products/ ... /index.htm
http://gcc.gnu.org/onlinedocs/
Oder im Terminal mit man gcc oder man gcc-4.2 bzw. in Kapitel VI.

ac_add_options --enable-prebinding
Aktiviert das Prebinding von OS X. Dies ist nur für ältere OS X-Versionen interessant. Für 10.4, 10.5 oder gar 10.6 wird dies nicht benötigt, erst recht nicht für Macs mit Intel-CPU. Standardmäßig ist Prebinding daher deaktiviert und unter comm-central/mozilla-central gibt es diese Option auch nicht mehr.

ac_add_options --enable-calendar bzw. ac_add_options --disable-calendar
Aktiviert bzw. deaktiviert die Erweiterung "Lightning" in Thunderbird 3.

ac_add_options --enable-debug bzw. ac_add_options --disable-debug
Schaltet den Entwickler-Modus ab (oder auch ein "enable-debug"). Das Abstellen bringt auch einen ganz kleinen Geschwindigkeitsvorteil.

ac_add_options --enable-crypto bzw. ac_add_options --disable-crypto
Aktiviert das Sicherheitsmodul (Personal Security Manager). Ohne diesen Manager gibt es zum Beispiel mit Hotmail Probleme. Daher ist das Aktivieren von Vorteil und standardmäßig aktiviert.

ac_add_options --enable-ldap bzw. ac_add_options --disable-ldap
LDAP ist das "Lightweight Directory Access Protocol", damit können Verzeichnisse über das TCP/IP-Netzwerk abgerufen werden. Das OS X-Adressbuch kann auch LDAP verwenden. Ist standardmäßig aktiviert und daher nicht (mehr) nötig. Seitdem Thunderbird auf comm-central umgezogen ist, darf diese Option nicht mehr verwendet werden, da dann die Kompilierung fehl schlägt.

ac_add_options --enable-mathml bzw. ac_add_options --disable-mathml
Mit MathML kann man mit einem MathML-Editor erzeugte Formeln anzeigen. Ist standardmäßig aktiviert.

ac_add_options --enable-svg bzw. ac_add_options --disable-svg
SVG = "Scalar Vector Graphics", ein Vektorgrafik-Format das zum Beispiel auch von Safari unterstützt wird. Ist standardmäßig aktiviert.

ac_add_options --enable-xft
Zum Aktivieren von Antialising (Kantenglättung).

ac_add_options --enable-update-packaging
Stellt sicher dass "Update Packaging" aktiviert ist, also Update-Pakete geladen werden können.

ac_add_options --enable-update-channel=release
Stellt den Update-Kanal auf die offizielle Version ein. Es gibt auch noch "=nightly" oder "=beta".

ac_add_options --enable-official-branding
Aktiviert das offizielle Mozilla-Branding. Builds mit diesem Branding dürfen nach Mozilla-Lizenzvertrag nur für den Eigengebrauch verwendet und nicht verteilt werden. Will man seine Thunderbird-Version verteilen muss man das offizielle Branding abstellen.
http://www.mozilla.org/foundation/trademarks/
https://developer.mozilla.org/en/Buildi ... stribution
Unterschieden werden kann ein offizieller Build von einem nicht-offiziellen Build anhand des Programmicons. Beispiel Thunderbird: Thunderbird offiziell und Thunderbird nicht-offiziell.

ac_add_options --enable-strip
Ist dies aktiviert werden beim Installationsvorgang Debugging-Symbole aus dem installierten Programm entfernt. Mit Debugging-Symbolen erhöht sich die Dateigröße des Programms. Ist standardmäßig deaktiviert.

ac_add_options --enable-tests bzw. ac_add_options --disable-tests
Hiermit wird das Erstellen von Test-Bibliotheken angestellt/unterdrückt. Diese werden nur für Debugging benötigt.

ac_add_options --enable-shark
Aktiviert das Profiling mittels Shark (Apple Developer Tools). Beispielmozconfig

ac_add_options --disable-accessibility
Hiermit wird die a11y-Unterstützung abgestellt.
http://en.wikipedia.org/wiki/Computer_accessibility

ac_add_options --enable-pango
Ist wichtig um asiatische Schriftzeichen wie Thai darstellen zu können. Verlangsamt aber auch das Rendering.

ac_add_options --enable-plaintext-editor-only
Stellt den HTML-Editor ab.

ac_add_options --disable-pedantic
Gibt alle Warnungen bekannt die durch ANSI C ausgelöst wurden.

ac_add_options --enable-xinerama
Aktiviert Xinerama.

ac_add_options --disable-compile-environment
Dies wird nur benötigt wenn man ein Language Pack erstellen will.

ac_add_options --with-distribution-id=ID
Gibt an wer der Ersteller/Verbreiter dieses Build ist, z.B bei "--with-distribution-id=polysom" wird hier polysom als Distributor angegeben.

Es gibt noch etliche andere Optionen, einige davon findet man zum Beispiel hier:
http://webtools.mozilla.org/build/config.cgi
http://developer.mozilla.org/en/docs/Us ... re_options
http://developer.mozilla.org/en/docs/Co ... ld_Options

Man sollte diese Optionen aber immer mit Bedacht einsetzen! Hier ist weniger oft mehr, man sollte auch nur Optionen verwenden bei denen man sich absolut sicher ist was sie bewirken!! Oft liegt ein Kompilierungsfehler in einer falschen oder nicht unterstützten Zeile in der mozconfig. Aus dem selben Grund sollte man alle Zeilen aus seiner mozconfig entfernen die man nicht wirklich benötigt! Ein Mozilla-Entwickler sagte mir dazu einmal "In general, you can assume that if an option would make things faster or better, we would have turned it on by default." Alle Optionen die standardmäßig aktiv sind können aus der Datei "configure.in" entnommen werden. Gerne werden dort manche Optionen auch entfernt weil sich kein Nutzen bzw. Nachteile herausgestellt haben.



-------------------------------
Zuletzt geändert von polysom am So Okt 10, 2010 18:18, insgesamt 9-mal geändert.
Bild
Solange Kakaobohnen an Bäumen wachsen, ist Schokolade für mich Obst.
Homepage - Securebird - Soundcloud - Mixcloud

polysom

Offline

Benutzeravatar


  • Wohnort: Dresden
2  Do Dez 24, 2009 13:45
:idee: Hinweis: Mit welcher mozconfig die offizielle Version kompiliert wurde kann man sich mit dem Befehl "about:buildconfig” ansehen. Für Thunderbird gibt man dies in den Einstellungen als Startseite an und startet TB dann neu. Für Firefox und Camino gibt man dies in die Adresszeile ein. :idee:


Wenn man will kann man nun noch bestimmte Patche anwenden um den Funktionsumfang der Applikation zu verändern. Dazu speichert man den Patch im Ordner /temp/mozilla als patch.diff.
Mit Patchen wird zum Beispiel auch von Developern (Bugzilla) überprüft ob ein bestehendes Problem/Sicherheitlücke in einem Release behoben werden kann, indem dieser Patch auf den Build angewendet wird um danach zu überprüfen ob das Problem/Sicherheitslücke dann noch besteht.

Dann wendet man den Patch an mit
$ patch -p1 < patch.txt

Gelegentlich wird die Datei configure.in gepatcht (Beispiel). Danach muss diese Datei regeneriert werden, dazu führt man im Terminal nach Anwendung des Patches $ autoconf213 aus. Hat man selbst eine Datei angepasst und will daraus nun einen anwendbaren Patch erstellen (z.B. für Bugzilla) geht man vor wie auf MDC beschrieben. Seinen Patch kann man dann vorher noch hier auf Fehler testen: http://beaufour.dk/jst-review/ Ein Script um Patche einfach einzufügen gibt es hier: http://robarnold.org/hg-qimport-my-bugzilla-patch/
Enthält ein Patch PNG-Bilder etc. als "GIT binary patch" lässt sich dies nicht mit obigem Befehl anwenden. Hier verwendet man dann am besten hg zum patchen:
$ hg import --no-commit -f /temp/src/patch.diff
Patche bei denen an der Beschreibung "WIP" ( = work in process) steht, sollten mit Vorsicht genossen werden da sie noch unfertig sind.

:idee: Wenn nicht benötigt kann der Schritt mit dem Patch auch weg gelassen werden, dies wird wohl der Regelfall sein. :idee:

Ändert man den Code und möchte einen Patch erstellen, gibt es dazu viele Möglichkeiten. Zum Beispiel:
$ hg diff -p -U 8 /temp/src > /meinpatch.txt
Hat man neue Dateien hinzugefügt muss man dies Mercurial vorher noch mitteilen mit:
$ hg add

Weiterführender Link: http://developer.mozilla.org/en/docs/Creating_a_patch



III. Ein Release-Build erstellen

Nun ist man an dem Schritt angelangt an dem man dem Computer den Befehl gibt das Programm aus dem Quellcode mit den angegebenen Einstellungen zusammenzubauen. Zuerst sollte man sich vergewissern, dass man alles benötigte hat. Also den Quellcode, die mozconfig und (bei lokalisierten Versionen) die Lokalisierungsdaten. Wenn ja, wechselt man in das Verzeichnis (als /temp/src oder /temp/mozilla) und startet das Kompilieren mit:
$ make -f client.mk build

Jetzt dauert das eine ganze Weile (ca. 2 Stunden auf einem PPC bzw. 20 min auf einem Intel-Mac). Wenn am Ende irgendwas mit "Error" steht hats nicht funktioniert. Ansonsten gibt man dann noch ein

$ make -C obj-powerpc-apple-darwin9.1.0/mail/installer

Je nach verwendeter OS-Version muss die Zahl (Darwin-Version) angepasst werden. 9.1.0 ist es für OS X 10.5.1, für OS X 10.4.11 wäre es zum Beispiel 8.11.0. Bei Firefox ist es natürlich nicht "mail" sondern "browser" (usw.).
Außerdem unterscheidet sich diese Zeile je nach Prozessor-Typ, bei einem Intel-Mac wäre es "...obj-i386-apple-darwin...".

Nun sollte ein (lokalisiertes) Thunderbird und ein DMG mit Thunderbird im Ordner /temp/mozilla/obj-powerpc-apple-darwin9.1.0/mozilla/dist (bzw. /temp/mozilla/obj-i386-apple-darwin9.1.0/mozilla/dist) liegen (bzw. das Programm welches man gebaut hat). Das DMG ist das was man benötigt. Alles andere kann man (wenn man nichts anderes mehr damit vor hat) in den Papierkorb werfen.

Die eigentlichen Schritte (Quellcode holen, mozconfig erstellen, make) dauern nur 10-15 Minuten, danach kann man dann was anderes machen und der Computer erledigt den Rest.

Fertig!!! :) :)


:!: Anmerkung: Das so erstellte Programm ist kein Universal Binarie. Auf einem PPC entsteht so eine PPC-only-Version und auf einem Intel-Mac eine Intel-only-Version.
Möchte man sein Programm gerne als UB erstellen muss man ein klein wenig anders vorgehen, siehe dazu unter "V. Das Programm als Universal Binarie erstellen". :!:

Benötigt man die sha1sum des DMGs geht das im Terminal mit:
$ openssl dgst -sha1 <file>



IV. Ein Trunk-Build erstellen

Bei einem Trunk handelt es sich um Vorabversionen (z.B. Thunderbird 3.3a1pre), die nicht zum täglichen Einsatz vorgesehen sind. Will man so etwas (z.B. als Entwickler oder aus Interesse) ausprobieren, kann man auf die fertigen Versionen auf dem Mozilla-Server zurückgreifen oder sich den Quellcode per Mercurial (Hg) holen. Trunks werden als sog. "Nightlys" angeboten. Ein Nightly Build, kurz Nightly, ist eine Software-Version die meist Nachts automatisch erstellt wird. Seit Sommer 2008 befindet sich der Quellcode der noch unveröffentlichten Versionen nicht mehr auf einer CVS-Distribution, sondern muss mittels Mercurial (Hg) geladen werden. Daher muss zuerst Mercurial und die dazugehörigen merge-Skripte installiert werden (siehe hier). Hat man oben mittels Macports schon Mercurial installiert muss man sich nur noch um die merge-Skripte kümmern. Nun gilt es noch zu unterscheiden welches Mozilla-Projekt man erstellen will. Thunderbird und SeaMonkey befinden sich auf comm-central und Firefox (und XULRunner) auf mozilla-central. Nun kommt noch hinzu, dass sich unter comm-central nur die Teile befinden, die Thunderbird-only sind, alles was sonst noch benötigt wird muss man sich dann hinterher noch von mozilla-central holen. Klingt komplizierter als es ist, es wird sicher klarer, wenn wir beginnen den Code zu holen. Doch vorher noch eine Anmerkung, unter Mercurial ist die Vorgehensweise ein wenig anders, wenn man einen lokalisierten Build erstellen will. Zum einen muss in der mozconfig angegeben werden wo die lokalisierten Daten liegen, zum anderen muss man sich diese Daten vor dem Kompilieren holen. Den Pfad in der mozconfig gibt man an mit der (neuen) Option "--with-l10n-base=$". Also für Thunderbird z.B. ac_add_options --with-l10n-base=/temp/src und für Firefox z.B. ac_add_options --with-l10n-base=/temp/mozilla.
Bevor man überhaupt mit dem Bauen anfängt sollte man sich über den momentanen Tinderbox-Status informieren:
Thunderbird3.0-Tinderbox
Thunderbird3.1-Tinderbox
Thunderbird Trunk-Tinderbox
Camino-Tinderbox
Firefox-Tinderbox
Ist der Status dort bei allen Boxen grün, kann bedenkenlos begonnen werden. Ist eine (oder gar mehrere) Boxen orange oder gar rot und am brennen, sollte unbedingt gewartet werden bis wieder alles im grünen Bereich ist. In so einem Fall stimmt etwas mit dem Quellcode nicht. Inzwischen kann eine Box auch lila werden, was auch ein schlechtes Zeichen ist.
Dies vorweg, dann fangen wir einfach mal an.
Dazu erstellen wir uns im Terminal erst einmal wieder unseren temporären Ordner:

$ mkdir /temp
$ cd /temp


Nun holt man sich den Quellcode (bei mir kommt es gelegentlich vor, dass iTunes das Quellcodeholen stört, daher beende ich zur Sicherheit zuerst alle Programme):

• Für Thunderbird oder SeaMonkey:
$ hg clone http://hg.mozilla.org/comm-central/ src
$ cd src


• Für Firefox oder XULRunner:
$ hg clone http://hg.mozilla.org/mozilla-central/ mozilla
$ cd mozilla


Will man einen lokalisierten Build erstellen folgt nun der Schritt an dem man sich die entsprechenden Daten holt. Für einen deutschen Build z.B.:
$ hg clone http://hg.mozilla.org/l10n-central/de/
Soll der Build nicht lokalisiert werden lässt man diesen Schritt einfach weg. Welche Sprachen alle möglich sind kann man in dieser Liste sehen. Ob irgendwelche Strings evtl. noch fehlen lässt sich hier und hier nachsehen, ist das der Fall sollte man noch warten ("Missing" sollte 0 sein bzw. alles grün).

Für Thunderbird oder SeaMonkey folgt danach noch ein
$ python client.py checkout
dann werden die fehlenden Bestandteile geladen (dauert!). Für Firefox ist dies nicht nötig.

Nun fügt man wie schon beschrieben seine mozconfig ein (beachte die Anmerkung unten!!) und wendet eventuell Patche an. Seit Gecko 2.0 gibt es keine statischen Thunderbird-Versionen mehr, sondern Thunderbird basiert auf libxul. Daher fällt hier "-static" und "-shared" weg. Dann kann wie schon beschrieben mit dem Kompilieren begonnen werden:

$ make -f client.mk build

Danach baut man wieder das DMG:

$ make -C obj-i386-apple-darwin9.4.0/mail/installer

Und hat dann einen fertigen Trunk-Build. :)

Eine mozconfig für Thunderbird 3.3 (libxul) unter comm-central könnte z.B. so aussehen:
CPU=`sysctl -a hw 2>&1 | grep 'hw.availcpu' | sed 's|hw.availcpu = *||'`
let J=$CPU*4

CC="gcc-4.2 -arch i386"
CXX="g++-4.2 -arch i386"
CFLAGS="-O3 -mieee-fp -fstack-protector-all -param=ssp-buffer-size=4 -fpeel-loops -march=core2 -ftree-vectorize -fno-tree-pre"
CXXFLAGS="${CFLAGS}"

# Options for cross-compilation on Snow Leopard.
HOST_CC="gcc-4.2"
HOST_CXX="g++-4.2"
RANLIB=ranlib
AR=ar
AS=$CC
LD=ld
STRIP="strip -x -S"
CROSS_COMPILE=1
ac_add_options --target=i386-apple-darwin$DARWIN_VERSION

# Options for client.mk.
mk_add_options MOZ_MAKE_FLAGS=-j${J}
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options MOZ_CO_LOCALES=de
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
mk_add_options AUTOCONF=autoconf213
mk_add_options BUILD_OPT=1

# Options for 'configure' (same as command-line options).
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk
ac_add_options --enable-macos-target=10.6
ac_add_options --enable-application=mail
ac_add_options --enable-optimize
ac_add_options --enable-update-packaging
ac_add_options --enable-update-channel=nightly
ac_add_options --enable-official-branding
ac_add_options --enable-ui-locale=de
ac_add_options --with-l10n-base=/Volumes/Developer/temp/src
ac_add_options --enable-strip
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --disable-calendar
ac_add_options --disable-crashreporter

Hinweis: Da in dieser mozconfig das offizielle Branding aktiviert ist, darf so ein Build nach Mozilla Foundation Trademark Policy nur für den Eigengebrauch verwendet werden, will man seinen Build verteilen muss man dies deaktivieren (die entsprechenden Zeilen löschen und/oder ein # vor die Zeile setzen). Die angegebene mozconfig stellt einen deutsch lokalisierten Build her, der auf Mac OS X 10.6 und einen Intel-Mac mit Core2(Duo)-Prozessor optimiert ist. Unter 10.6 wird standardmäßig ein 64bit-Build erstellt, daher ist hier noch ein Cross-Compile-Teil eingefügt, damit eine 32bit-Version entsteht (siehe unten bei 64bit).
Zuletzt geändert von polysom am So Okt 10, 2010 18:27, insgesamt 6-mal geändert.
Bild
Solange Kakaobohnen an Bäumen wachsen, ist Schokolade für mich Obst.
Homepage - Securebird - Soundcloud - Mixcloud

polysom

Offline

Benutzeravatar


  • Wohnort: Dresden
3  Do Dez 24, 2009 13:45
:!: Anmerkung: Seit Mercurial darf in die mozconfig keine Zeile wie ". $topsrcdir/mail/config/mozconfig" mehr enthalten sein, hier reicht ein "--enable-application=xy". Außerdem wird eine Zeile "mk_add_options MOZ_CO_PROJECT=" nicht mehr benötigt. Ansonsten kommt es zu einem Kompilierungsfehler. Kompilierungsoptionen in der mozconfig, die schon länger veraltet sind (wie "--enable-ldap") dürfen unter Mercurial ebenfalls nicht mehr verwendet werden. Dies führt hier ebenfalls zu Kompilierungsfehlern. Neu ist hier z.B. die schon oben erwähnte Option "--with-l10n-base=$" um den Pfad zu l10n-Dateien anzugeben. :!:

Weiterführende Links:
http://wiki.mozilla.org/MailNews:HgSwitchover
http://developer.mozilla.org/en/docs/Ho ... stem_works
http://devmo.dekiwiki.mozilla.org/en/Mercurial
http://developer.mozilla.org/en/docs/Co ... (Mercurial)
http://developer.mozilla.org/en/docs/Mo ... (Mercurial)
http://developer.mozilla.org/en/docs/comm-central
http://developer.mozilla.org/en/docs/Mercurial_FAQ
http://wiki.mozilla.org/SeaMonkey:hg-based_build
http://developer.mozilla.org/en/docs/L10n_on_Mercurial



V. Das Programm als Universal Binarie erstellen

Wenn man das Ganze als Universal Binarie basteln möchte muss man die Vorgehensweise etwas modifizieren. Zum einen benötigt man die "Universal-mozconfig" (oder wie das Ding auch immer heißen mag). Diese hat den Pfad mozilla/build/macosx/universal/mozconfig.

Als nächstes fügt man folgende Zeilen in seine eigene mozconfig ein:
if test -e "$topsrcdir/mozilla/build/macosx/universal/mozconfig"; then
. $topsrcdir/mozilla/build/macosx/universal/mozconfig
else
. $topsrcdir/build/macosx/universal/mozconfig
fi


Also zum Beispiel:
if test -e "$topsrcdir/mozilla/build/macosx/universal/mozconfig"; then
. $topsrcdir/mozilla/build/macosx/universal/mozconfig
else
. $topsrcdir/build/macosx/universal/mozconfig
fi

CPU=`sysctl -a hw 2>&1 | grep 'hw.availcpu' | sed 's|hw.availcpu = *||'`
let J=$CPU*4

CC=gcc-4.2
CXX=g++-4.2

## Options for client.mk.
mk_add_options MOZ_MAKE_FLAGS=-j${J}
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options MOZ_CO_LOCALES=de
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
mk_add_options AUTOCONF=autoconf213
mk_add_options BUILD_OPT=1

# Options for 'configure' (same as command-line options).
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk
ac_add_options --enable-macos-target=10.6
ac_add_options --enable-application=mail
ac_add_options --enable-optimize
ac_add_options --enable-update-packaging
ac_add_options --enable-update-channel=nightly
ac_add_options --enable-official-branding
ac_add_options --enable-ui-locale=de
ac_add_options --with-l10n-base=/Volumes/Developer/temp/src
ac_add_options --enable-strip
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --disable-calendar
ac_add_options --disable-crashreporter

Hinweis: Da in dieser mozconfig das offizielle Branding aktiviert ist, darf so ein Build nach Mozilla Foundation Trademark Policy nur für den Eigengebrauch verwendet werden, will man seinen Build verteilen muss man dies deaktivieren (die entsprechenden Zeilen löschen und/oder ein # vor die Zeile setzen).

Vor Gecko 2.0 entstand so ein PPC/i386-UB, ab Gecko 2.0 entsteht so ein i386/x86_64-UB. PPC wird ab Gecko 2.0 nicht mehr unterstützt.

Auf einem PPC muss am letzten make-Schritt nun noch zusätzlich ein "-w" mit eingefügt werden (bei den vorhergehenden ist dies nicht unbedingt nötig).
$ make -w -f client.mk
Auf Intel-Macs nicht (warum auch immer).

Dann folgt noch ein:
$ make -C obj-x86_64-apple-darwin10.4.0/x86_64/mail/installer
(Auch hier muss je nach OS-Version die Darwin-Version bzw. der Prozessortyp angeglichen werden)

Und fertig ist das DMG mit dem UB-Programm (das DMG liegt unter bj-x86_64-apple-darwin10.4.0/Architektur/mozilla/dist).

:idee: Hinweis: Es ist sicherzustellen dass mindestens GCC 4.2 verwendet wird, da mit GCC 3.3 (wurde früher auch oft mit den Developer Tools installiert) ein Erstellen von UB-Programmen nicht möglich ist! Außerdem sollte man beachten dass das Erstellen eines Programms als UB mehr Rechenzeit in Anspruch nimmt. :idee:

Weiterführender Link: http://developer.mozilla.org/en/docs/Ma ... l_Binaries



VI. Den Build optimieren, Performance-Steigerung

Nach dem man erfolgreich einen oder mehrere Builds erstellt hat, kann man sich daran machen (wenn man will) und die Performance etwas erhöhen. Sozusagen "Pimp my Mozilla App" :D Für diesen Zweck gibt es mehrere Möglichkeiten.

1. Die Performance lässt sich steigern indem man das Einbauen von Debug-Symbole abstellt. Außerdem kann man alle Tests abstellen.
ac_add_options --disable-debug
ac_add_options --disable-tests


2. Auch erhöht sich die Performance wenn man den Build nicht mit einer shared Library, sondern mit einer statischen erstellt.
ac_add_options --enable-static
ac_add_options --disable-shared

Geht aber nur für Thunderbird vor Gecko 2.0, Firefox und Thunderbird/SeaMonkey ab Gecko 2.0 setzen auf libxul. Libxul ist von der Performance vergleichbar mit einem statischen Build.

3. Sehr viel Experiementierspielraum gibt es in Bezug auf die FLAGs.
CFLAGS="X" und CXXFLAGS="X"

Es gibt eine Reihe von FLAGs die sich hier anwenden lassen (für das "X" einsetzen). Die offiziellen Builds werden in der Regen erstellt mit ac_add_options --enable-optimize um zu jedem Modul moduleigene Optimierungsoptionen (MODULE_OPTIMIZE_FLAGS) anzuwenden. Diese werden bei Verwendung von ac_add_options --enable-optimize="X" überschrieben, daher ist es angeraten zur Optimierung CFLAGS="X" und CXXFLAGS="X" zu verwenden, z.B.:
CC="gcc-4.2"
CXX="g++-4.2"
CFLAGS="X"
CXXFLAGS="${CFLAGS}"
ac_add_options --enable-optimize

Link1, Link2, Link3.

Die FLAGs sind abhängig vom verwendeten Compiler und der Version des Compilers. Die gängigsten FLAGs (für GCC) sind:


-O0, -O1, -O2, -O3, -Os und -Oz
Dies gibt die Optimierungsstufen an. Mit -O0 wird angegeben nicht zu optimieren. -O1,2,3 gibt an zu optimieren, je nach Zahl wird etwas mehr optimiert (1 = ein wenig, 2 = mittel, 3 = stark). Je nach Stufe werden hier andere Optionen aktiviert (näheres siehe gcc manual), -O3 wird in der Regel nicht empfohlen, da es in seltenen Fällen zu fehlerhaftem Code kommen kann. -Os optimiert auf Dateigröße, aber ohne Einbußen bezüglich Geschwindigkeit. -Oz optimiert ebenfalls auf Dateigröße ohne sich jedoch um Geschwindigkeit zu kümmern.
Tipp: Will man sich einmal genau ansehen welche einzelnen Funktionen bei welcher O-Funktion aktiviert ist, geht das im Terminal. Zum Beispiel für -O2 und gcc 4.2:
echo 'int main(){return 0;}' > test.c && gcc-4.2 -v -Q -O2 test.c -o test && rm test.c test

-g
Dies fügt Debugging-Code in die kompilierten Objektdateien ein und ist daher für Debug-Builds gedacht. Es wird davon abgeraten -g mit einer -O - Option zu verwenden.

-pipe
Gibt an, dass die Abarbeitung der Befehle während dem Kompilieren über Pipes und nicht über temporäre Dateien geschehen soll. Dies darf beim Debuggen mit -save-temps (siehe unten) nicht angewendet werden.

-save-temps
Dies ist nur für Debugging interessant. Hiermit wird angegeben, dass der sonst temporäre Zwischencode (preprocessed source) gespeichert werden soll. (Schema) Dieser muss/sollte z.B. bei einem Bugreport mitgeliefert werden. (Link) -save-temps steht im Widerspruch mit -pipe.

-pthread
Gibt an, dass Multithreading verwendet werden soll. Dies ist unter OS X standardmäßig aktiviert.

-mabi=altivec
Erweitert die Programmierschnittstelle mit Altivec, dies ist nur für Macs mit PowerPC-Prozessor interessant.

-faltivec
Aktiviert die Unterstützung für die Altivec-Erweiterung, wie sie im Motorola AltiVec Technology Programming Interface Manual (PIM) definiert sind. Auch dies ist nur für Macs mit PowerPC-Prozessor interessant.

-mmmx
Aktiviert im Build die von Intel entworfene SIMD-Technik "MMX" (Multi Media Extension). Dies ist für Macs mit Intel-Prozessor von Interesse.

-mfpmath=387 und -mfpmath=sse
Generiert eine Fließkommaarithmetik für eine Intel 387 Fließkomma Einheit bzw. die von Intel entwickelte Befehlssatzerweiterung "SSE". Dies ist für Macs mit Intel-Prozessor von Interesse. 387 wird meist für eine i386-Architektur vorgeschlagen und sse für x86_64. Wobei meist angeraten wird diese Option ganz wegzulassen, da sie den Code sehr verbiegen kann. Näheres hierzu ist unbedingt dem GCC-Manual zu entnehmen.

-msse, -msse2, -msse3, -mssse3 und -msse4.1
Aktiviert im Build die von Intel entworfenen SIMD-Techniken "SSE". Hier sollte man Acht geben welche Erweiterung von dem Prozessor seines Macs unterstützt wird und nur diese aktivieren. SSE4 kann erst seit gcc4.3 bzw. Apples gcc4.2 aktiviert werden (wobei -msse4 sowohl SSE4.1 als auch SSE4.2 aktiviert!). Dies ist für Macs mit Intel-Prozessor von Interesse. Will man sich informieren welche Erweiterungen der eigene Prozessor unterstützt geht dies im Terminal mit sysctl -a, die Erweiterungen stehen dann unter "machdep.cpu.features".

-march= und -mcpu=
Gibt an auf welchem CPU-Typ das Programm laufen soll, so kann ein Programm auf einen bestimmten CPU-Typ zugeschnitten werden. Dies sollte daher nur verwendet werden wenn das Programm nur für einen bestimmten CPU-Typ vorgesehen ist. So optimiert z.B. -mcpu=7450 auf den Prozessor eines G4+ PPC, -mcpu=G5 auf G5 PPC und -march=core2 (erst ab gcc4.3 bzw. Apples gcc4.2) auf Intel-Macs mit Core2Duo-CPUs. Je nach angegebenem Prozessor werden gleichzeitig unterschiedliche Befehlserweiterungen angeschalten, siehe hierzu unbedingt das gcc manual.

-mtune=
Optimiert den Code auf einen bestimmten Prozessor-Typ, so dass dieser darauf besser läuft. Hier kann alles verwendet werden das auch für -march= bzw. -mcpu= verwendet werden kann. Mit -mtune=generic wird der Code auf die gängigsten Prozessoren optimiert und -mtune=native (erst ab gcc4.3 bzw. Apples gcc4.2) überprüft während dem Kompilieren den CPU-Typ des Rechners und optimiert den Code exakt auf diesen Prozessor.

-funroll-loops
Rollt Schleifen ab dessen Anzahl von Iterationen (= Dauer der Schleife) während der Kompilierungszeit ermittelt werden kann oder wenn sie vor dem Schleifeneintritt bekannt ist. Dadurch werden diese Schleifen in einzelne Codezeilen aufgelöst. Dies kann das Binary schneller machen, aber auch langsamer (einfach ausprobieren), auf jeden Fall macht es den Code größer.

-fpeel-loops
Schält eine Schleife, es entfernt z.B. Schleifen mit einer kleinen Anzahl an Iterationen. Dies kann den Code schneller machen, da eine geschälte Schleife durch andere Optimierungsschritte besser optimiert werden kann. Das beste Ergebnis erhält man mit dieser Funktion bei profilierten Builds (PGO).

-ftree-loop-linear
Führt eine lineare Schleifentransformation des Verzeichnisbaums durch. Dies kann die Cache-Performance erhöhen und gibt die Möglichkeit für weitere Schleifen-Optimierungen frei. In sehr selten Fällen kann dies zu fehlerhaftem Code führen, macht den Code aber auch schneller.

-funswitch-loops
Befördert Zweige mit Bedingungen welche Schleifen unveränderlich machen aus der Schleife. Gibt es z.B. ein if() mit einer Bedingung welche die Schleife unveränderlich macht innerhalb der Schleife, dann wird der Code so umgeordnet, dass der bedingte Sprung außerhalb der Schleife vorgenommen wird. Dies führt gewöhnlich zu einer besseren Performance und zu größerem Code. Dies wird automatisch durch -O3 angeschalten.

-funsafe-loop-optimizations
Aktiviert eine weitergehende Loop-Optimierung, indem z.B. angenommen wird, dass Loops endlich sind und Loop-Kenzahlen nicht überlaufen (auch wenn der Loop-Optimierer diese Annahme nicht überprüfen kann).
Diese Option ist unsicher und kann den Code zerstören.
Zuletzt geändert von polysom am So Okt 10, 2010 17:58, insgesamt 2-mal geändert.
Bild
Solange Kakaobohnen an Bäumen wachsen, ist Schokolade für mich Obst.
Homepage - Securebird - Soundcloud - Mixcloud

polysom

Offline

Benutzeravatar


  • Wohnort: Dresden
4  Do Dez 24, 2009 13:45

-ftree-loop-im
Ist ähnlich wie -funswitch-loops, befördert ebenfalls Zweige mit Bedingungen welche Schleifen unveränderlich machen, aber nur solche welche auf RTL-Level schwer handhabbar wären, aus der Schleife. Wird diese Funktion zusammen mit -funswitch-loops verwendet wird eine triviale Varianzanalyse durchgeführt.

-fno-tree-pre
Stellt das PRE (Partial Redundancy Elimination) auf Verzeichnissbäume ab, welches bei -O2 und -O3 aktiviert ist. Kann in einigen Fällen den Code schneller machen.

-fstack-protector und -fstack-protector-all
Kompiliert das Programm mit "Stack Smashing Protection (SSP), ProPolice)" (Schutz vor Pufferüberläufen). Stack Protection ist Bestandteil von Mac OS X seit Version 10.5 und Apple schützt Quicktime damit vor Hacker-Angriffen. Das Programm wird dadurch aber auch größer (bis 12%). -fstack-protector schützt nur Funktionen mit Character-Arrays, wohingegen -fstack-protector-all alle Funktionen schützt. -Wstack-protector gibt hier eine Warnung falls eine Funktion nicht geschützt wird. Mit -param=ssp-buffer-size= kann der Arraygrößen-Schwellenwert der SSP angegeben werden, meist wird hier -param=ssp-buffer-size=4 verwendet. Es soll Probleme geben wenn SSP zusammen mit -O3 verwendet wird.

-minline-all-stringops
Standardmäßig führt GCC eine Inline-Expansion nur bei einigen Zeichenketten durch. Hiermit wird festgelegt, dass die Inline-Expansion öfter durchgeführt werden soll. Dies erhöht die Performance, führt aber auch zu einem größeren Code.

-fivopts
Optimiert Induktionsvariablen (Link).
Zuletzt geändert von polysom am Di Jun 08, 2010 13:30, insgesamt 1-mal geändert.
Bild
Solange Kakaobohnen an Bäumen wachsen, ist Schokolade für mich Obst.
Homepage - Securebird - Soundcloud - Mixcloud

polysom

Offline

Benutzeravatar


  • Wohnort: Dresden
5  Do Dez 24, 2009 13:45

-ftracer
Führt "Tail-Duplication" durch. Durch Parallelität kann die Abarbeitung von sequentiellem Programmcode beschleunigt werden. Damit die erzeugte Parallelität aber tatsächlich ausgenutzt werden kann (um den Code in minimaler Zeit auszuführen) werden die Grundblöcke durch Tail-Duplication vergrößert indem der Code dupliziert wird. Dies vereinfacht die Arbeit für andere Optimierungsschritte. (Link)

-fweb
Bei Optimierungsschritten übersetzt der GNU-C-Compiler zuerst in eine Zwischensprache, die Register Transfer Language (RTL), welche einen abstrakten Prozessor modelliert und Pseudo-Register zur Verfügung stellt. Mit -fweb wird ein Netz aus Abhängigkeiten erzeugt und jedes Netz einem solchen Pseudo-Register zugeordnet. Wenn gcc nun Register zuweisen muss hat der Compiler schon eine Liste der besten Kandidaten auf die er zurückgreifen kann. Dies vereinfacht dem Compiler außerdem Schleifen zu optimieren und unnützen Code zu entfernen, macht allerdings in manchen Fällen Debugging unmöglich. In manchen Fällen kann -fweb (nach meiner Erfahrung) eine Anwendung langsam machen.

-ftree-vectorize
Stellt Schleifen in Verzeichnissbäumen so um, dass sie SIMD-Befehle besser verwenden können. Daher sollte auf PPC-Platformen zusätzlich ein -maltivec und auf Intel-Platformen eine/mehrere -msse-Option zusätzlich angewendet werden (Link). Durch die Vektorisierung kann eine Instruktion mehrere Operationen durchführen (Link). In Apples GCC wird dadurch automatisch -fstrict-aliasing aktiviert.

-fstrict-aliasing
Erlaubt dem Compiler die schärfsten Aliasing-Regeln anzuwenden welche die Programmiersprache kennt. Durch Aliasing ist es möglich Daten die im Zwischenspeicher liegen durch verschiedene symbolische Namen aufzurufen. Die Regel des "strict aliasing" erlaubt eine Erhöhung der Performance, kann aber zu unkorrektem Code führen.

-ftree-parallelize-loops
Diese Funktion ist erst seit Version 4.3 in GCC enthalten, fehlt aber leider in Apples GCC4.2. Hiermit werden Schleifen parallelisiert und das Programm somit auf Multicore-Systeme optimiert. Diese Option impliziert -pthread und funktioniert somit auch nur, wenn -pthread auch funktioniert.

-fopenmp
Hiermit werden OpenMP-Konstrukte zur Parallelverarbeitung innerhalb eines Knotens eines Symmetrischen Multiprozessorsystems ausgenutzt. Das so kompilierte Programm nimmt dann die Anzahl der gleichzeitig und parallel in Hardware ausführbaren Threads als Maß, um zu entscheiden, wie viele Software-Threads es startet. Dies kann auf Multiprozessorsystemen die Ausführung des Programms beschleunigen. Kurz gesagt, man kompiliert auf Multicore-Unterstützung.
Warnung: Ein mit diesem Flag kompiliertes Programm kann evtl. auf einem anderen (als dem eigenen) Rechner nicht funktionieren. Es wird in der ausgegebenen Fehlermeldung dann nach der Komponente "libgomp" gesucht, z.B. Library not loaded: /usr/local/lib/libgomp.1.dylib. Soll das Programm verteilt werden ist es daher besser auf diesen FLAG zu verzichten.

-finline-functions
Hierdurch werden alle einfachen Funktionen in ihren Aufrufer integriert und es entsteht Inline-Code (im gleichen Modul). Der Compiler entscheidet dabei welche Funktion einfach genug ist um integriert zu werden. Dies wird durch -O3 automatisch aktiviert. Nach meiner Erfahrung macht diese Funktion einen Build auch instabil (häufige Abstürze) und/oder langsamer.

-mieee-fp
Gibt an, dass Gleitkommazahl-Vergleiche nur IEEE 754-konform durchgeführt werden dürfen. Dafür werden auch Optimierungsoptionen, welche diese Kriterien nicht erfüllen, abgestellt. Dies kann die Performance nachteilig beeinflussen, erhöht aber die Präzision.

-fsee
Entfernt überflüssige Instruktionen und bewegt die nicht überflüssigen mittels LCM an einen optimalen Platz. Ist in GCC4.2/4.3 noch ein wenig fehlerhaft und kann dort zu Fehlkompilierungen führen.

-fgcse-after-reload
Hiermit werden überflüssige Spillings bei der Registerzuteilung verhindert. Dies kann die Performance verbessern und wird durch -O3 aktiviert.

-fforce-addr
Erzwingt das Kopieren von Speicheradress-Konstanten in Register bevor daran Berechnungen durchgeführt werden. Dies ist keine Größenoptimierung, aber eine Performanceoptimierung und kann zu besserem Code führen. Wenn man sich nicht sicher ist ob es benötigt wird sollte man es lieber weglassen (kann das Programm nämlich auch langsamer und träger machen). Diese Option kann zu einer Optimierung von Loops beitragen und produziert vor allem dann optimierten Code, wenn sie zusammen mit Aliasing-Optionen und -Ox verwendet wird.

-maccumulate-outgoing-args
Der maximal benötigte Umfang für ausgehende Argumente wird im Prolog der Funktion berechnet. Dies ist auf modernen CPUs schneller, verbessert die Ablaufplanung. Der Nachteil ist eine erheblich größere Datei (um rund 8%).

-frtl-abstract-sequences
Wird verwendet um die Dateigröße zu verringern indem identische Teile an Code in eine Subroutine verarbeitet werden. Verringert allerdings ein wenig die Performance.

-finline-limit=n
n muss eine Zahl gleich oder größer als Null sein. Diese Funktion gibt die maximale Größe einer Funktion an, auf die inline angewendet wird. Eine größere Zahl kann das Programm schneller machen und erhöht die Kompilierzeit, eine zu große Zahl erhöht aber auch den Code Bloat. Häufig verwendet wird hier n=8000. Der Standardwert ist n=600. Auch zusätzliche Optionen werden hier gerne verwendet, wie: "-finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000"

-fno-trapping-math
Manche mathematischen Operationen können zu Fehlern führen, wie log(-1). Daher schleichen Kompiler um solche Operationen herum, auf Kosten der Performance. -fno-trapping-math gibt dem Kompiler die Information, dass die Fließpunkt-Arithmetik keine Fallen an irgendeinem Input erzeugt. Ist sinnvoll, wenn das Programm IEEE "non-stop" Fließpunkt-Arithmetik verwendet. Macht der Erfahrung nach JavaScript-basierte Programme schneller.



Vor dem Verwenden von Optionen sollte man sich darüber im gcc Manual informieren, zu finden im Internet oder übers Terminal mit $ man gcc bzw. $ man gcc-4.2. Wobei zu beachten ist, dass Apple seine eigenen gcc-Versionen hat, deren Versionsnummern sich von den offiziellen gcc-Versionen unterscheiden. So enthält Apples gcc4.2 Befehlssätze die in der offiziellen Version erst seit gcc4.3 enthalten sind.
:idee: Man kann sich die Manpages auch als PDF speichern, dazu gibt man im Terminal z.B.
Code: Alles auswählen
man -t gcc > /Users/polysom/Desktop/gcc.ps && ps2pdf /Users/polysom/Desktop/gcc.ps
ein und speichert die auf dem Desktop entstandene PS-Datei mit Vorschau als PDF. :idee:

Warnung: Es gibt einige CFLAGs die man nicht verwenden sollte, da sie nach meiner Erfahrung zu fehlerhaftem Code führen und ein Programm entsteht das nicht startfähig ist! Hierzu zählt -fast und bei älterem Mozilla-Code -fomit-frame-pointer. Bei aktuellem Mozilla-Code funktioniert -fomit-frame-pointer gut, wenn man es nur zur JS-Optimierung verwendet und nicht auf das gesammte Programm anwendet. Mac OS X benutzt nicht, wie die meisten anderen UNIX-Systeme, das ELF-Format für Binaries, sondern Mach-O. Daher bringen hier auch ELF-CFLAGs nichts.

:idee: Will man sich die besten Flags automatisch ermitteln lassen, kann man das mit Acovea tun, zumindest wenn man es kompiliert bekommt. :idee:

Verwendet man Clang oder ICC zum Kompilieren, verwendet man natürlich dementsprechend angepasste FLAGs.


Eine Performance-Steigerung ist natürlich erst dann etwas wert, wenn man sie messen und damit vergleichen kann. Zu diesem Zweck gibt es die Performance-Tools von Mozilla (Link 1, Link 2).
Auch zu diesem Zweck sind die Performance Tools der Apple Developer-Tools gedacht, zu finden in /Developer/Applications/Performance Tools
Darüber informiert man sich am besten auf der Seite von Apple.
Zuletzt geändert von polysom am So Okt 10, 2010 18:01, insgesamt 2-mal geändert.
Bild
Solange Kakaobohnen an Bäumen wachsen, ist Schokolade für mich Obst.
Homepage - Securebird - Soundcloud - Mixcloud

polysom

Offline

Benutzeravatar


  • Wohnort: Dresden
6  Do Dez 24, 2009 13:45
Die Startzeit seines Programms lässt sich z.B. mit dem Perl Skript startup-unix.pl von Mozilla ermitteln. Man bekommt dies auf die selbe Weise wie man sich den Quellcode seines Programms beschafft hat, nur dass man nun
$ cvs co mozilla/tools/performance/startup
eingibt und wartet bis alles geladen ist. Wichtig sind nun 3 Dateien hieraus. Die Datei "startup-unix.pl" kann man z.B. in den Ordner /usr/bin ablegen. Die Datei "gettime.pl" kommt in den Perl-Ordner des Systems (/System/Library/Perl/5.8.8.). Und die Datei "startup-test.html" legt man in seinen User-Ordner. Nun ist es noch ganz nützlich sich das Modul Time::HiRes zu installieren (falls es nicht schon installiert ist). Das geht ganz einfach im Terminal mit:
$ sudo perl -MCPAN -e 'install Time::HiRes'
Beim ersten Start muss man vorher noch CPAN konfigurieren, das dauert eine Weile.
Sind die Vorbereitungen abgeschlossen lassen sich damit die Startzeiten von Firefox und Camino ermitteln. Dazu geht man wie folgt vor, z.B. für Camino gibt man ins Terminal ein:
$ startup-unix.pl /Applications/Camino.app/Contents/MacOS/Camino
Dann erhält man eine Antwort wie:
cmd = /Applications/Camino.app/Contents/MacOS/Camino -url "file:/Users/polysom/startup-test.html?begin=1215684183459"
und Camino wird gestartet und zeigt die Startzeit in Millisekunden an. Man sollte allerdings bedenken, dass ein Programm beim ersten Start immer länger braucht als bei den darauf folgenden (XPCOM Autoregistrierung, Chrome Registrierung). Außerdem sollte ein Mittelwert (von mindestens 7 Messungen) erstellt werden um gute vergleichbare Ergebnisse zu erhalten. Alle Größen die die Startzeit beeinflussen können (Programme/Prozesse im Hintergrund...) sollten bedacht und ggf. eliminiert werden.
Die Startzeit von Thunderbird lässt sich auf diese Weise nicht ermitteln.

Seit Version 3.0b2 ist es möglich in Thunderbird den SunSpider JavaScript Benchmark Test auszuführen. Dazu definiert man in den Einstellungen einfach die Seite http://www2.webkit.org/perf/sunspider-0 ... river.html als Startseite und startet Thunderbird neu. In Versionen vor 3.0b2 ist dies leider nicht möglich.

Ein Java-Funktionalitions-Test ist mit folgender Seite möglich: http://www.java.com/en/download/help/testvm.xml

Weiterführende Links:

http://gcc.gnu.org/onlinedocs/
http://developer.apple.com/documentatio ... gcc.1.html
http://developer.apple.com/DOCUMENTATIO ... 4.2.1/gcc/
http://www.unix-tutorials.com/go.php?id=396
http://de.wikipedia.org/wiki/Compiler#P ... Chrlich.29
http://www.mozilla.org/performance/mac-performance.html
http://wiki.mozilla.org/Performance:Tinderbox_Tests
http://developer.apple.com/tools/performance/
http://www.info.uni-karlsruhe.de/lehre/ ... rungen.pdf
Bild
Solange Kakaobohnen an Bäumen wachsen, ist Schokolade für mich Obst.
Homepage - Securebird - Soundcloud - Mixcloud

polysom

Offline

Benutzeravatar


  • Wohnort: Dresden
7  Do Dez 24, 2009 15:44
VII.Tipps zur Fehlersuche & Debugging

Treten Probleme auf ist es gelegentlich ganz hilfreich ein Log-Protokoll zu erstellen und sich die Prozesse etwas genauer anzusehen. Dazu braucht man einen Build in dem man das Logging nicht deaktiviert hat (--disable-logging). Dann erstellt man sich eine Datei mit dem Namen "logging.command" (z.B. mit Smultron) mit dem Inhalt:
Code: Alles auswählen
#!/bin/sh
export NSPR_LOG_MODULES=all:5
export NSPR_LOG_FILE=Thunderbird.log
/Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin &

Diese macht man im Terminal ausführbar mit $ sudo chmod a+x /logging.command
Klickt man nun doppelt auf die Datei startet sich Thunderbird und es werden alle Mailnews-Prozesse in einer Datei "Thunderbird.log" im User-Ordner abgelegt. Es lassen sich auch andere Prozesse loggen. Näheres siehe hier:
https://wiki.mozilla.org/MailNews:Logging

Gelegentlich wird bei Problemen auch empfohlen das Programm im safe mode zu starten um zu sehen ob das Problem von einem Add-On etc. stammt. Wie dies geht ist hier nachzulesen: http://kb.mozillazine.org/Safe_mode

Auch oft hilfreich ist die Möglichkeit den Mozilla-Quellcode gezielt zu durchsuchen: http://mxr.mozilla.org/
Siehe außerdem im Kapitel zur Optimierung unter -save-temps.

Tests lassen sich durchführen, wenn man sein Programm mit ac_add_options --enable-tests erstellt hat. Dann wechselt man in die OBJDIR und starten den entsprechenden Test. Möglich sind:


$ make check

$ make xpcshell-tests
make reftest

$ make crashtest

$ make mochitest-plain

$ make mochitest-chrome

$ make mochitest-browser-chrome

$ make mochitest-a11y


Will man nur ganz bestimmte Test durchführen, z.B. nur die Gloda Mozmill-Tests:

$ make -C mailnews/db/gloda/test/ xpcshell-tests


Und möchte man nur einen ganz bestimmten Test durchführen, z.B. nur test_mime_emitter.js:

$ make -C mailnews/db/gloda/test SOLO_FILE=test_mime_emitter.js check-one



Will man einem Fehler (z.B. wenn die Anwendung bei einer bestimmten Aktion dauernd abstürzt) genauer auf die Schliche kommen geht dies mit Debugging. Am einfachsten geht das mit gdb (GNU Debugger) und/oder Xcode. Dazu muss man von seinem Programm zuerst ein Debug-Build erstellen (einen unlokalisierten en-US build):
Code: Alles auswählen
ac_add_options --enable-debug --disable-optimize
ac_add_options --enable-shared --disable-static

bzw.
Code: Alles auswählen
ac_add_options --enable-debug --disable-libxul

Dieser Debug-Build ist natürlich extrem langsam und auch nur für Debugging-Zwecken gedacht. Zum Debuggen mit gdb startet man nun seinen Debug-Build und sucht sich in der Aktivitätsanzeige die PID des laufenden Programmes heraus (oder im Terminal: $ ps ax | grep thunderbird). Dann verknüpft man im Terminal das laufende Programm mit gdb:
Code: Alles auswählen
$ gdb /Pfad/zu/objdir-debug/mozilla/dist/ThunderbirdDebug.app/Contents/MacOS/thunderbird-bin -p [PID des Programms, ohne Klammern]

Nachdem gdb gestartet wurde gibt man gdb die Anweisung das Programm auszuführen indem man einfach $ c eingibt. Bei einem Crash etc. wird nun im Terminalfenster der Verursacher dafür angegeben. Will man anstatt dessen einen Backtrace aller laufender Threads, dann gibt man anstatt dem "C" ein: $ thread apply all bt.
Für Debugging mit Xcode siehe hier.

Es ist auch möglich nur einzelne Komponenten zu Kompilieren, wenn man versuchen will darin einen Fehler zu finden (dann muss man nicht extra deswegen das komplette Projekt kompilieren). Um zu überprüfen ob JS als 64bit-Binarie kompilierbar ist z.B. wie folgt:
$ CC="gcc-4.2 -arch x86_64" CXX="g++-4.2 -arch x86_64" AR=ar CROSS_COMPILE=1 /temp/src/mozilla-central/js/src/configure --target=x86_64-apple-darwin
Dies ist natürlich nach Belieben anpassbar.

Weiterführende Links:
https://wiki.mozilla.org/MailNews:Logging
https://developer.mozilla.org/en/Debugging_on_Mac_OS_X
https://developer.mozilla.org/en/Debugg ... ng_on_OS_X
http://www.gnu.org/software/gdb/documentation/
http://sourceware.org/gdb/current/onlin ... b_toc.html
https://wiki.mozilla.org/Performance:Leak_Tools
http://developer.apple.com/tools/gcc_overview.html



VIII. Profile-Guided Optimization (PGO)

PGO ist eine Technik mit der man seinen Build noch weiter optimieren kann. Die Prozedur ist dabei vergleichbar mit einer 2-Pass Codierung im Videobereich. Daher dauert Kompilieren als PGO auch ungefähr doppelt so lange wie Kompilieren ohne PGO! Bei der PGO-Prozedur wird auf die verwendete Prozessor-Architektur optimiert, der Cache wird besser genutzt, es wird eine bessere Sprungvorhersage (Branch Predictions) durchgeführt und das Programm insgesamt besser optimiert. Bei meinen Versuchen wird außerdem das Programm mit PGO um exakt 2,0% kleiner. Die Prozedur verläuft hierbei in 3 Schritten. Im ersten Schritt wird das Programm gebaut und dabei analysiert. Im zweiten Teil wird das erstellte Programm gestartet und ein Profil erstellt. Und im letzten Teil wird das Programm mit den eben ermittelten optimierten Parametern erstellt. Für Mozilla-Programme geht man dafür wie folgt vor:

1. In der mozconfig muss mit mk_add_options PROFILE_GEN_SCRIPT angegeben werden, dass ein PGO-Build erstellt werden soll. Will man das selbe Script benutzen wie es auch für die Nightly Builds verwendet wird, fügt man ein:

mk_add_options PROFILE_GEN_SCRIPT='$(PYTHON) $(MOZ_OBJDIR)/_profile/pgo/profileserver.py'

Erstellt man ein UB muss der Pfad natürlich dementsprechend abgeändert werden (...$(MOZ_OBJDIR)/ppc/_profile/pgo...) bzw. "i368" anstatt "ppc" auf einem Intel-Mac!! Man kann auch ein selbst geschriebenes Script (Perl, Phyton etc.) verwenden, näheres dazu siehe im weiterführenden Link.

2. Anstatt wie sonst üblich mit $ make -f client.mk oder $ make -w -f client.mk (UB auf PPC) startet man das Kompilieren mit
$ make -f client.mk profiledbuild

bzw.
$ make -w -f client.mk profiledbuild


Dann wird der Build-Prozess zuerst ganz normal durchgeführt, danach wird kurz das erstellte Programm gestartet und statistisch die optimalen Parameter ermittelt, dann das eben erstellte Programm wieder gelöscht und das Programm ganz neu mit den eben ermittelten optimalen Parametern erstellt.
Im ersten Teil wird zur Ermittlung der Parameter die Option -fprofile-generate aktiviert, im zweiten Teil zum Anwenden der optimalen Parametern die Option -fprofile-use. Mit -fprofile-generate werden automatisch auch aktiviert: -fprofile-arcs, -fprofile-values und -fvpt. Mit -fprofile-use aktiviert sich automatisch -fbranch-probabilities, -fvpt, -funroll-loops, -fpeel-loops und -ftracer. Näheres hierzu ist dem GCC-Manual zu entnehmen.

Schlägt das hier gezeigte automatische PGO-erstellen fehl, kann man einen PGO-Build auch auf folgende Art erstellen:
Code: Alles auswählen
$ make -f client.mk build MOZ_PROFILE_GENERATE=1
$ export NO_EM_RESTART=1
$  mkdir /temp/src/obj-i386-apple-darwin9.5.0/_profileprofile
$ /temp/src/obj-i386-apple-darwin9.5.0/mozilla/dist/Thunderbird.app/Contents/MacOS/thunderbird-bin -no-remote -profile /temp/src/obj-i386-apple-darwin9.5.0/_profileprofile
#(Im nun gestarteten Programm ein paar willkürliche Aktionen ausführen und es danach wieder manuell beenden.)
$ make -f client.mk clean
$ make -f client.mk build MOZ_PROFILE_USE=1
$ make -C obj-i386-apple-darwin9.5.0/mail/installer

Zu den Command Line Optionen siehe hier.
Nach meiner Erfahrung ist der PGO-Prozess sehr empfindlich gegenüber außerdem Einflüssen (im Hintergrund laufende Prozesse etc.). Ich melde mich daher vor dem Build-Prozess ab und neu an. Außerdem sollte man beachten dass es einige CFLAGs gibt die bei einem normalen Build-Prozess keine Probleme verursachen, aber (warum auch immer) bei PGO-Builds.

Weiterführender Link: http://developer.mozilla.org/en/docs/Bu ... timization



IX. Eine 64bit Executable erstellen

Momentan ist es nur möglich Firefox als 64bit-Anwendung zu erstellen. Comm-central ist noch nicht 64bit-fähig, weshalb das Kompilieren hier momentan noch fehl schlägt. Sobald sich dies ändert werde ich diesen Abschnitt hier anpassen.
Ein modernes Programm kann als 32bit- oder 64bit-Executable vorliegen. Der Unterschied ist, dass ein 32bit-Programm maximal 4 GB an RAM bzw. virtuellem Speicher adressieren kann und ein 64bit-Programm bis zu 16 EB. Es profitieren also nur Programme von 64bit, wenn sie viel RAM benötigen (Verschlüsselungsalgorithmen, aufwendige graphische- und multimediale Berechnungen, Suchalgorithmen, Arbeiten mit großen Datenmengen...). Man sollte sich also gut überlegen ob es überhaupt Sinn macht sein Programm in 64bit zu erstellen. Zumal 64bit neue Nachteile mit sich bringt. Zum einen benötigt ein 64-Bit Programm mehr virtuellen Speicher als ein 32bit-Programm. Zum anderen sollte der Quellcode auf 64bit optimiert sein. Arbeiten mit 64bit-Programmen kann unter OS X 10.4 (Tiger) zu Problemen führen und funktioniert erst ab OS X 10.5 (oder höher) problemlos.
64bit ist erst seit Gecko 2.0 möglich und nur ab Mac OS X 10.6. Unter 10.6 entsteht automatisch eine 64bit-Version. Will man unter 10.6 aber eine i386-Version erstellen, muss man in seine mozconfig noch einen Cross-Compile-Teil einfügen:

Code: Alles auswählen
CC="gcc-4.2 -arch i386"
CXX="g++-4.2 -arch i386"

# Options for Cross-Compilation on Snow Leopard.
HOST_CC="gcc-4.2"
HOST_CXX="g++-4.2"
RANLIB=ranlib
AR=ar
AS=$CC
LD=ld
STRIP="strip -x -S"
CROSS_COMPILE=1
ac_add_options --target=i386-apple-darwin$DARWIN_VERSION

Mehr zum Cross-Compilation-Teil siehe hier. Dies funktioniert nur für Intel-Platformen, ppc64 wird nicht unterstützt. 64bit-Unterstützung gibt es in Gecko erst seit dem 15.12.2009. Die mit Macports installierten Ausführdateien und Bibliotheken müssen, dank Cross-Compilierung, nur als Host-Architektur vorliegen.


Weiterführende Links: http://developer.apple.com/documentatio ... ion_1.html
http://developer.apple.com/macosx/64bit.html
http://developer.apple.com/documentatio ... ementID_21
http://developer.apple.com/documentatio ... emory.html
https://developer.mozilla.org/en/Mac_OS ... ompilation
https://bugzilla.mozilla.org/show_bug.cgi?id=468509

X. Grand Central Dispatch

Seit Mac OS X 10.6 gibt es das libdispatch Framework welches die Unterstützung von Mehrkernprozessoren verbessert. Damit wird es sehr erleichtert das Programm auf die Nutzung mehrerer Prozessorkerne hin zu optimieren. Verwendet man libdispatch in seinem Programm läuft dieses allerdings auch erst ab 10.6 oder höher.
Um libdispatch in sein Programm einzuführen ist es initial nur nötig die Zeile
Code: Alles auswählen
#include <dispatch/dispatch.h>

oder
Code: Alles auswählen
#import <dispatch/dispatch.h>

in die entsprechende Quelldatei einzufügen. Da der Quellcode von Mozilla-Applikationen sehr viele Quelldateien enthält ist es nicht ganz einfach zu entscheiden in welche Datei man diese Zeile einfügt. Ich bin daher den Weg gegangen und habe diese Zeile nur in Quelldateien eingefügt die schon OS X - Frameworks mit einbinden und z.B. eine Zeile wie " #import <Cocoa/Cocoa.h>" o.ä. enthalten.
Es gibt einige Dateien die man lieber außen vor lassen sollte, da sonst das Kompilieren zu einem Error führt, hierzu zählt prtypes.h und Dateien im Ordner "qcms".
Will man etwas tiefer gehen muss der Quellcode für GCD umgeschrieben werden, doch dazu sind Programmierkenntnisse nötig.
Wird dispatch eingeführt ist ein Compiler notwendig der Blocks unterstützt, wie llvm oder Clang.

Weiterführende Links:

http://www.macresearch.org/cocoa-scient ... nd-central
http://libdispatch.macosforge.org/
http://developer.apple.com/mac/library/ ... eue_create
http://arstechnica.com/apple/reviews/20 ... 0-6.ars/12
http://images.apple.com/euro/macosx/tec ... 090608.pdf


XI. Lightning (Kalender)

Lightning ist der integrierte Kalender in Thunderbird, der optional als Plugin (Add-On) installiert werden kann.
http://www.mozilla.org/projects/calendar/
http://ftp.mozilla.org/pub/mozilla.org/ ... g/nightly/
Hierbei muss man immer darauf achten dass die Thunderbird-Version mit der Lightning-Version kompatibel ist. Eigentlich sollte der Kalender in die finale Version von Thunderbird 3.0 integriert werden, dies wurde dann aber auf einen späteren Zeitpunkt verschoben. Will man sich selbst eine Version von Thunderbird mit integriertem Kalender erstellen fügt man in seine mozconfig einfach
Code: Alles auswählen
--enable-calendar

mit ein. Sodann entsteht eine Thunderbird-Version mit einer lokalisierten Kalender-Integration.
Zuletzt geändert von polysom am So Okt 10, 2010 18:36, insgesamt 6-mal geändert.
Bild
Solange Kakaobohnen an Bäumen wachsen, ist Schokolade für mich Obst.
Homepage - Securebird - Soundcloud - Mixcloud

polysom

Offline

Benutzeravatar


  • Wohnort: Dresden
8  Do Dez 24, 2009 15:44
XII. Enigmail

Enigmail ist eine Erweiterung für Thunderbird zum Signieren und Verschlüsseln von EMails durch den offenen PGP-Standard (OpenPGP). Die Erweiterung funktioniert daher nur wenn man PGP installiert hat. Dies ist auch mit MacPorts möglich ($ sudo port install gnupg2).
Enigmail lässt sich selbst kompilieren, dazu benötigt man zuallererst den Quellcode. Diesen bekommt man von hier. Dieser wird abgelegt unter /src/mailnews/extensions/enigmail/. Will man ein Enigmail-Trunk Build erstellen läd man sich den Code einfach in dieses Verzeichnis mit:
$ cd /temp/src/mailnews/extensions
$ cvs -d :pserver:guest@mozdev.org:/cvs co enigmail/src
Enigmail such die .mozconfig leider im Verzechnis /temp/src/mailnews weshalb man dort auch eine Version ablegen sollte. Außerdem kann es sein dass Enigmail einige Dateien an einem Ort sucht andem sie nicht sind, diese müssen dann einfach alle dorthin kopiert werden (kopieren, nicht verschieben!).
Nachdem dies geschehen ist muss zuerst einmal Thunderbird gebaut werden, da Enigmail einige vorkompilierte Komponenten benötigt.
Danach wechselt man dann in das Enigmail-Verzeichnis und verknüpft die nötigen Dateien miteinander:
$ cd /temp/src/mailnews/extensions/enigmail/src
$ ./makemake -o /temp/src/obj-x86_64-apple-darwin10.2.0
Danach kann dann das Kompilieren von Enigmail gestartet werden mit $ make, und falls ein installierbares xpi gewünscht wird erhält man dies danach mit $ make xpi. Dies befindet sich dann unter /temp/src/obj-x86_64-apple-darwin10.2.0/mozilla/dist/bin.

Thunderbird selbst enthält zum Signieren und Verschlüsseln von EMails ein eingebautes S/MIME-Modul. Hierfür ist also keine Erweiterung mehr nötig.
Da die Entscheidung ob man PGP oder S/MIME zum Verschlüsseln seiner EMails verwendet einem Glaubenskrieg ähnelt, will ich hier nicht näher darauf eingehen. Wer seine Emails verschlüsseln möchte findet hierzu im Netz oder in Büchern mehr als genügend zum Nachschlagen. Ihren Zweck erfüllen auf jeden Fall beide Methoden ;).

XIII. Einen Fehler an Mozilla melden (Bugzilla)

1. Entdeckt man einen Fehler in Thunderbird, Firefox etc. gilt es als erstes zu überprüfen ob dieser Fehler reproduzierbar ist. Dazu löscht man den Inhalt seines User-Cache-Ordners (/User/Library/Cache), startet seinen Mac neu und überprüft ob der Fehler immer noch vorhanden ist. Man sollte darauf achten, dass man die neuste offizielle Version besitzt, ansonsten sollte man seine Version aktualisieren. Ist der Fehler reproduzierbar gilt es nun zu überprüfen ob der Fehler von Thunderbird/Firefox etc. oder von einem Add-On oder einer sonstigen Erweiterung stammt.

2. Um zu überprüfen ob der Fehler mit einem Add-On oder einer sonstigen eigenen Veränderung des Programmes zu tun hat startet man das Programm im Safe-Mode. Dazu öffnet man das Terminal und gibt dort folgendes ein:
Für Firefox:
Code: Alles auswählen
/Applications/Firefox.app/Contents/MacOS/firefox-bin -safe-mode

Für Thunderbird
Code: Alles auswählen
/Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin -safe-mode

Link: http://kb.mozillazine.org/Safe_mode
Ist der Fehler dann immer noch zu sehen handelt es sich um einen Bug, den man an Mozilla melden sollte. Dazu überprüft man zuerst ob der Fehler auch in der amerikanischen Version (en-US) des Programmes zu finden ist oder ob der Fehler mit einer fehlerhaften Lokalisierung zu tun hat. Sollte der Fehler hingegen von einem Plugin stammen, sollte der Entwickler dieses Plugins benachrichtigt werden.

3. Um die Mozilla-Entwickler auf einen Fehler aufmerksam zu machen gibt es Bugzilla: https://bugzilla.mozilla.org/
Dort benötigt man zuerst einen Account (es muss nur die Email-Adresse und ein Login angegeben werden).
Bevor man einen Fehler allerdings an Mozilla meldet sollte man über die Suchfunktion feststellen ob der Fehler schon gemeldet wurde, also schon aktenkundig ist. Sehr viele gemeldete Fehler sind Duplikate. Dazu benutzt man die Suche: https://bugzilla.mozilla.org/query.cgi
Hier kann man zwischen einer einfachen und einer erweiterten Suchfunktion wählen. Werden mit der einfachen Suche zu viele Treffer angezeigt ist es ratsam die Suche über die erweiterten Einstellungen einzugrenzen. Hier sollte man aber verschiedene Möglichkeiten ausprobieren. Zum Beispiel findet man Bugs die Thunderbird und Firefox betreffen unter "Core" als Componente. Diesen Bug würde man nicht finden, würde man die Suche auf Thunderbird oder Firefox eingrenzen. Ist der Fehler nicht zu finden kann man einen neuen Bug in Bugzilla eröffnen.

4. Einen neuen Bug in Bugzilla eröffnen: Um einen Bug zu eröffnen muss man sich zuerst einloggen. Dann klickt man oben auf "New" und eine Auswahl an Programmen erscheint. Hier wählt man sein Programm/Komponente mit der man Probleme hat aus. Wie man dann schon erkennt ist die Sprache in Bugzilla Englisch. Es ist also alles das man in Bugzilla schreibt auf Englisch zu verfassen. Beim Verfassen des Bugreports ist es ganz hilfreich die korrekte Bezeichnugn der einzelnen Fenster zu kennen, eine kleine übersicht findet sich hier.
Oben bekommt man dann zuerst noch einmal die neusten Bugs zu sehen, hier kann man nochmal durchblättern ob der Fehler nicht doch schon gemeldet wurde.
Nun wählt man die Komponente aus bei der der Fehler auftritt, in grün gibt es rechts noch einen Erklärungstext. Findet man hier nichts passendes wählt man das Passendste aus, die Entwickler werden dann wenn nötig die Komponente selbst anpassen. Dann wählt man die Hardware und das Betriebssystem aus auf dem der Fehler auftritt. Ist es ein Problem das unabhängig von Hardware und Betriebssystem ist, wählt man hier "All" aus. Nun kommt etwas Wichtiges und zwar der Build Identifier. Dieser gibt an um welchen Build es sich handelt, damit die Entwickler den Fehler besser eingrenzen können. Man findet ihn wenn man im Programm auf "über..." geht. So etwas sieht dann z.B. so aus:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b2pre) Gecko/20081118 Thunderbird/3.0b1pre
Unter "Summary" wird nun sozusagen die überschrift des Bugs angegeben. Dies bildet dann auch den Betreff der Benachrichtigungsmail über diesen Bug an die Entwickler. Hier ist es wichtig den Bug mit möglichst wenigen Worten möglichst präzise zu beschreiben.
Unter "Details" beschreibt man dann den Fehler so genau wie möglich. Also worum es sich genau handelt, wann der Fehler auftritt und wie sich der Fehler äußert.
Bei "Steps to Reproduce" gibt man nun Schritt für Schritt an wie man den Fehler hervorrufen kann. So dass jeder dies nachmachen kann und dann den beschriebenen Fehler erhält. Bei "Actual Results" gibt man dann an was passiert wenn man diesen Schritten folgt und bei "Expected Results" das was eigentlich passieren sollte.
Die anderen Dinge sind dann selbsterklärend. Hat man alles eingetragen überprüft man nochmal alles, auf Rechtschreibfehler und ob man nicht doch noch etwas vergessen hat. Ist man soweit zufrieden kann man seinen Bug mit einem Klick auf "Submit Bug Report" melden.
Nun ist es noch möglich Anhänge anzufügen, z.B. einen Screenshot des Fehlers oder einen Crash-Log, das Ergebnis eines Debugging-Versuchs oder sonst etwas das den Entwicklern helfen könnte.
Dann heißt es zu warten was mit dem gemeldeten Bug passiert. In der Regel kümmert sich noch am selben Tag einer darum und sei es nur um ihn als Duplikat zu lösen. Und keine Sorge, die Entwickler sind alle sehr nett und helfen einem auch, wenn sie merken dass man noch neu ist.

Wie man auf Bugzilla sieht, kann man hier nicht nur Fehler melden, sondern auch Verbesserungen/Änderungen die man gerne im Programm haben würde.

Weiterführende Links: https://developer.mozilla.org/en/Bug_writing_guidelines


Viel Erfolg! :)

XIV. Anhang 1 (Nützliches, Tipps & Tricks):

Um seine eigene mozconfig zu entwickeln ist es oft von Vorteil die mozconfig der offiziellen Versionen zu kennen. Die mozconfigs der aktuellen Versionen von Firefox und Thunderbird (Release, Debug, Nightly) lassen sich hier nachlesen: http://hg.mozilla.org/build/buildbot-configs/file/



:idee: Tipp: Da ich häufiger Thunderbird 3 baue habe ich mir ein Skript erstellt das die jeweiligen Schritte automatisch ausführt und mir dann das fertige DMG auf den Schreibtisch legt. Für TB 3 (Trunk) sieht das bei mir wie folgt aus:

Code: Alles auswählen
#!/bin/bash
growlnotify -m "Ein 32-bit Thunderbird wird erstellt. Bitte etwas Geduld!"

#Hole den Quellcode und erstelle eine mozconfig
mkdir /Volumes/Developer/temp
cd /Volumes/Developer/temp
hg clone http://hg.mozilla.org/comm-central/ src
cd src
hg clone http://hg.mozilla.org/l10n-central/de/
cp -f /Developer/ExtraMozillaFiles/.mozconfig /Volumes/Developer/temp/src
python client.py checkout --mozilla-repo=http://hg.mozilla.org/mozilla-central/ --skip-chatzilla --skip-venkman

#Lösche Reste einer vorhergehenden Kompilierung, kompiliere neu, erstelle ein DMG und verschiebe es auf den Desktop
rm -rf /Volumes/Developer/temp/src/obj-x86_64-apple-darwin10.3.0
make -f client.mk build
make -C obj-x86_64-apple-darwin10.3.0/mail/installer
cp -f /Volumes/Developer/temp/src/obj-x86_64-apple-darwin10.3.0/mozilla/dist/thunderbird-3.2a1pre.de.mac.dmg /Users/polysom/Desktop
mv /Users/polysom/Desktop/thunderbird-3.2a1pre.de.mac.dmg /Users/polysom/Desktop/thunderbird-3.2a1pre.de.\($(date +%d-%m-%Y)\).mac.dmg

#Prüfe ob das Erstellen des Programms erfolgreich war
files="/Volumes/Developer/temp/src/obj-x86_64-apple-darwin10.3.0/mozilla/dist/Thunderbird.app/Contents/MacOS/thunderbird-bin"
for file in $files; do
  if [[ -a $file ]]; then
    afplay /System/Library/Components/CoreAudio.component/Contents/Resources/SystemSounds/system/burn\ complete.aif
    growlnotify -t 'Status:' -m "Erstellung des Thunderbird Builds erfolgreich beendet. Das Programm wird nun in den Programme-Ordner verschoben."
   
    # Mounte das Image auf dem Desktop, verschiebe das Programm mittels HFSCompress in den Programme-Ordner und aktualisiere das Verzeichnis
    hdiutil attach /Users/polysom/Desktop/thunderbird-3.2a1pre.de.\($(date +%d-%m-%Y)\).mac.dmg
    rm -rf /Applications/Thunderbird.app
    ditto --hfsCompress /Volumes/Thunderbird/Thunderbird.app /Applications/Thunderbird.app
    touch -c /Applications/Thunderbird.app
    touch -c /Applications
    hdiutil detach /Volumes/Thunderbird
    else
    afplay /System/Library/Sounds/Funk.aiff
    growlnotify -a 'Problem Reporter' -t 'Status:' -m "Erstellung des Thunderbird Builds fehlgeschlagen!"
  fi
 done
exit 0
#


Oder für einen PGO-Build:
Code: Alles auswählen
#!/bin/bash
growlnotify -m "Ein Thunderbird PGO Build wird erstellt. Dieser muss nach dem Start manuell geschlossen werden um fortzufahren!"
mkdir /Volumes/Developer/temp
cd /Volumes/Developer/temp
hg clone http://hg.mozilla.org/comm-central/ src
cd src
hg clone http://hg.mozilla.org/l10n-central/de/
# hg clone http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/de/
cp -f /Developer/ExtraMozillaFiles/.mozconfig /Volumes/Developer/temp/src
cp -f /Developer/ExtraMozillaFiles/patch.diff /Volumes/Developer/temp/src
python client.py checkout --mozilla-repo=http://hg.mozilla.org/mozilla-central/ --skip-chatzilla --skip-venkman
patch -p1 < patch.diff
hg import --no-commit -f /Developer/ExtraMozillaFiles/patch64.diff
make -f client.mk build MOZ_PROFILE_GENERATE=1
export NO_EM_RESTART=1
mkdir /Volumes/Developer/temp/src/obj-x86_64-apple-darwin10.2.0/_profileprofile
afplay /System/Library/Sounds/Submarine.aiff
/Volumes/Developer/temp/src/obj-x86_64-apple-darwin10.2.0/mozilla/dist/Thunderbird.app/Contents/MacOS/thunderbird-bin -no-remote -profile /Volumes/Developer/temp/src/obj-x86_64-apple-darwin10.2.0/_profileprofile
make -f client.mk clean
make -f client.mk build MOZ_PROFILE_USE=1
make -C obj-x86_64-apple-darwin10.2.0/mail/installer
cp -f /Volumes/Developer/temp/src/obj-x86_64-apple-darwin10.2.0/mozilla/dist/thunderbird-3.1a1pre.de.mac.dmg /Users/polysom/Desktop
mv /Users/polysom/Desktop/thunderbird-3.1a1pre.de.mac.dmg /Users/polysom/Desktop/thunderbird-3.1a1pre.de.\($(date +%d-%m-%Y-10.6-PGO)\).mac.dmg
afplay /System/Library/Components/CoreAudio.component/Contents/Resources/SystemSounds/system/burn\ complete.aif
exit 0
#

Hierbei auch Danke an Moon für die Hilfe mit der Zeile für das automatische Umbenennen.

Mit $ chmod a+x wird das Skript ausführbar gemacht. Meine mozconfig und Patche welche ich anwenden möchte habe ich dazu einfach in einen Ordner /Developer/ExtraMozillaFiles gelegt. Die mozconfig kann ich dann ggf. einfach mit $ sudo pico /Developer/ExtraMozillaFiles/.mozconfig ändern.
:idee:


XIV. Anhang 2 (user.js, UserChrome.css und UserContent.css):

Das Aussehen und der Funktionsumfang einer Mozilla-Applikation lässt sich (außer mit Plugins) mit Hilfe der Dateien user.js, UserChrome.css und UserContent.css verändern. Diese Dateien müssen zuvor erstellt werden und sind im User-Verzeichnis in die entsprechenden Projekt-Ordner zu legen. Zum Beispiel für Thunderbird: User/Library/Thunderbird/Profiles/vge8b101.default/user.js und /Users/Library/Thunderbird/Profiles/vge8b101.default/chrome/UserChrome.css. Der Ordner "vge8b101.default" heißt bei jedem anders. Der Funktionsumfang dieser Dateien ist sehr groß, näheres darüber lässt sich im Internet finden (z.B. hier).

Folgender Eintrag in UserContent.css färbt in Thunderbird z.B. zitierte Texte unterschiedlich ein (Link):
/* Farben zitierter Nachrichten */
blockquote[type=cite] {
color: navy ! important; background-color: RGB(245,245,245) !important;
}
blockquote[type=cite] blockquote {
color: maroon ! important; background-color: RGB(235,235,235) !important;
}
blockquote[type=cite] blockquote blockquote {
color: green ! important; background-color: RGB(225,225,225) !important;
}
blockquote[type=cite] blockquote blockquote blockquote {
color: purple ! important; background-color: RGB(215,215,215) !important;
}
blockquote[type=cite] blockquote blockquote blockquote blockquote {
color: teal ! important; background-color: RGB(205,205,205) !important;
}


Und folgender Eintrag in UserChrome.css ändert Schriftart und Schriftgrad der Folderpane-Beschriftung:
/* Folder pane font */
#folderTree > treechildren::-moz-tree-cell-text {
font-size: 8pt !important;
font-family: Lucida Grande; font-weight:bold;
}


Einträge der user.js haben folgende Gestalt:
// Set Color of links in messages to #0033ff
user_pref("browser.anchor_color", "#0033ff");

// Remove > quote marks
user_pref("mail.quoted_graphical", false);
user_pref("mailnews.display.disable_format_flowed_support", true);

// Disable spotlight
user_pref("mail.spotlight.enable", false);


Weiterführende Links:
http://freenet-homepage.de/jetztundhier ... rbird.html
http://freenet-homepage.de/jetztundhier/firefox.html
http://forums.mozillazine.org/viewtopic.php?p=1491524
http://www.mozilla.org/unix/customizing.html
https://developer.mozilla.org/en/Command_Line_Options






Weiterführende Links (gesamt):
http://developer.mozilla.org/en/docs/Bu ... umentation
http://wiki.mozilla.org/Mac:Build_Requirements
http://developer.mozilla.org/en/docs/Bu ... _Extension
http://wiki.mozilla.org/Calendar:Build
http://www.mozilla.org/projects/thunderbird/themes.html
http://themes.mozdev.org/tutorial.html
http://www.mathinfo.net/files/themes/firefoxguide.pdf
http://forums.mozillazine.org/
http://www.rumblingedge.com/
http://wiki.mozilla.org/MailNews:HgSwitchover
http://developer.mozilla.org/en/docs/Ho ... stem_works
http://devmo.dekiwiki.mozilla.org/en/Mercurial
http://developer.mozilla.org/en/docs/Co ... (Mercurial)
http://developer.mozilla.org/en/docs/Mo ... (Mercurial)
http://developer.mozilla.org/en/docs/comm-central
http://developer.mozilla.org/en/docs/Mercurial_FAQ
http://wiki.mozilla.org/SeaMonkey:hg-based_build
Bild
Solange Kakaobohnen an Bäumen wachsen, ist Schokolade für mich Obst.
Homepage - Securebird - Soundcloud - Mixcloud

Zurück zu Wie & Was

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder