distcc - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

distcc - verteilter C/C++/ObjC-Compiler mit distcc-Pump-Erweiterungen

ZUSAMMENFASSUNG

distcc [COMPILER OPTIONEN]

distcc [COMPILER OPTIONEN]

[COMPILER OPTIONEN]

distcc [DISTC OPTIONEN]

BESCHREIBUNG

distcc verteilt die Kompilierung von C-Code auf mehrere Maschinen in einem Netzwerk. distcc
sollte immer die gleichen Ergebnisse liefern wie eine lokale Kompilierung, es ist einfach zu installieren und
verwenden, und es ist oft viel schneller als eine lokale Kompilierung.

Diese Version enthält Plain distcc sowie eine Erweiterung namens Pump Mode oder
distcc-Pumpe.

Für jeden Job sendet distcc im Plain-Modus den kompletten vorverarbeiteten Quellcode und
Compilerargumente über das Netzwerk vom Client zu einem Kompilierungsserver. In Pumpe
Modus sendet distcc den Quellcode und die rekursiv eingebundenen Header-Dateien (mit Ausnahme derer
aus den Standard-Systemheaderverzeichnissen), sodass sowohl die Vorverarbeitung als auch die Kompilierung
auf den Kompilierungsservern erfolgen kann. Dies beschleunigt die Lieferung von Zusammenstellungen um
bis zu einer Größenordnung über normalem distcc.

Die Kompilierung wird von einem Client-Computer gesteuert, bei dem es sich normalerweise um die Workstation des Entwicklers handelt
oder Laptop. Der distcc-Client läuft auf diesem Rechner, ebenso make, der Präprozessor (wenn
Der Pumpmodus von distcc wird nicht verwendet), der Linker und andere Phasen des Build-Prozesses. Irgendein
Eine Reihe von freiwilligen Maschinen fungieren als Kompilierungsserver und helfen dem Client beim Erstellen der
Programm, indem Sie das distccd(1) Daemon, C-Compiler und Assembler nach Bedarf.

distcc kann entweder über TCP-Sockets (standardmäßig auf Port 3632) oder über einen Tunnel laufen
Befehl wie ssh(1). Für TCP-Verbindungen müssen die Freiwilligen die distccd(1) Dämon
entweder direkt oder von inetd. Für SSH-Verbindungen muss distccd installiert sein, sollte aber
nicht auf Verbindungen achten.

TCP-Verbindungen sollten nur in sicheren Netzwerken verwendet werden, da kein Benutzer vorhanden ist
Authentifizierung oder Schutz des Quell- oder Objektcodes. SSH-Verbindungen betragen normalerweise 25 %
langsamer wegen des Prozessor-Overheads für die Verschlüsselung, obwohl dies stark variieren kann
abhängig von CPUs, Netzwerk und dem zu erstellenden Programm.

distcc soll mit GNU Makes verwendet werden -j Option, die mehrere Compiler ausführt
Prozesse gleichzeitig. distcc verteilt die Jobs auf lokale und Remote-CPUs.
Da distcc den größten Teil der Arbeit über das Netzwerk verteilen kann, ist eine höhere
Parallelitätsebene als für lokale Builds verwendet werden. Als Faustregel gilt: -j Wert
sollte auf etwa das Doppelte der Gesamtzahl der verfügbaren Server-CPUs eingestellt werden, aber abhängig von
Client-Einschränkungen. Diese Einstellung ermöglicht eine maximale Verschachtelung der blockierten Aufgaben
Warten auf Datenträger- oder Netzwerk-E/A. Beachten Sie, dass distcc auch mit anderen Build-Steuerelementen arbeiten kann
Tools wie SCons, bei denen ähnliche Parallelitätseinstellungen angepasst werden müssen.

Das -j Einstellung, insbesondere bei großen Werten von -J, muss die CPU-Last am
der Kunde. Möglicherweise sind zusätzliche Maßnahmen erforderlich, um die Belastung des Clients zu verringern. Zum Beispiel,
Concurrent Linking sollte mit Hilfe von Hilfssperren stark eingeschränkt werden. Der Effekt von
andere Build-Aktivitäten, wie die Java-Kompilierung beim Erstellen von gemischtem Code, sollten
betrachtet. Die --localslots_cpp Parameter ist standardmäßig auf 16 eingestellt. Dies begrenzt die
Anzahl gleichzeitiger Prozesse, die eine Vorverarbeitung im normalen distcc-Modus (ohne Pumpen) durchführen.
Daher größer -j Werte als 16 können verwendet werden, ohne einen Einzel-CPU-Client zu überlasten
wegen Vorbearbeitung. Solche großen Werte können Teile des Builds beschleunigen, die dies nicht tun
beinhalten C-Kompilierungen, aber sie sind möglicherweise nicht nützlich, um die Effizienz im normalen Modus zu unterscheiden.

Im Gegensatz dazu ist im Pumpenmodus und sagen wir 40 Servern eine Einstellung von -j80 oder größer kann sein
auch für Single-CPU-Clients geeignet.

Es wird dringend empfohlen, auf allen Computern dieselbe Compilerversion zu installieren
an einem Bau teilnehmen. Inkompatible Compiler können zu mysteriösen Kompilierungen oder Verknüpfungen führen
Misserfolge

SCHNELLSTART

1 Laden Sie für jeden Computer distcc herunter, entpacken Sie ihn und installieren Sie ihn.

2 Führen Sie auf jedem der Server distccd --dämon mit --ermöglichen Möglichkeiten zur Einschränkung
zugreifen.

3 Geben Sie die Namen der Server in Ihrer Umgebung ein:
$ export DISTCC_HOSTS='localhost rot grün blau'

4 Baue!
$ make -j8 CC=distcc

SCHNELLSTART FÜR DISTCC-PUMPE MODE

Gehen Sie wie oben vor, geben Sie jedoch in Schritt 3 an, dass die Remote-Hosts die Last von
Vorverarbeitung und dass die über das Netzwerk gesendeten Dateien komprimiert werden sollten:

$ export DISTCC_HOSTS='--randomize localhost red,cpp,lzo green,cpp,lzo
blau,cpp,lzo'

Das - randomisieren Option erzwingt eine einheitliche Verwendung von Compile-Servern. Während du bekommst
Einige profitieren vom Pumpmodus von distcc mit nur wenigen Servern, Sie erhalten zunehmende Vorteile
mit mehr Server-CPUs (bis zu den Hunderten!). Wickeln Sie Ihren Build in den Pumpbefehl ein,
hier unter der Annahme von 10 Servern:

$ distcc-pump make -j20 CC=distcc

WIE EBENE (NICHT-PUMPE) DISTCC Bestellt?

distcc führt den Compiler und Assembler immer nur remote aus. Mit plain distcc, die
Der Präprozessor muss immer lokal ausgeführt werden, da er auf verschiedene Header-Dateien zugreifen muss
die lokale Maschine, die auf dem Freiwilligen möglicherweise nicht vorhanden oder nicht dieselbe ist. Die
Linker muss in ähnlicher Weise Bibliotheken und Objektdateien untersuchen und muss daher lokal ausgeführt werden.

Compiler und Assembler benötigen nur eine einzige Eingabedatei (die vorverarbeitete Quelle) und
erzeugen eine einzelne Ausgabe (die Objektdatei). distcc versendet diese beiden Dateien über die
Netzwerk und kann daher den Compiler/Assembler remote ausführen.

Glücklicherweise ist der Präprozessor für die meisten Programme, auf denen der Präprozessor läuft, relativ billig, und die
Linker wird als relativ selten bezeichnet, sodass die meiste Arbeit verteilt werden kann.

distcc untersucht seine Befehlszeile, um festzustellen, welche dieser Phasen aufgerufen werden, und
ob der Job verteilt werden kann.

WIE DISTCC-PUMPE MODE Bestellt?

Im Pumpenmodus führt distcc den Präprozessor auch aus der Ferne aus. Dazu muss der Präprozessor
Zugriff auf alle Dateien, auf die es zugegriffen hätte, wenn es lokal ausgeführt worden wäre. In
Daher sammelt distcc alle rekursiv enthaltenen Header mit Ausnahme der
diejenigen, die Standard-Systemheader sind, und sendet sie zusammen mit der Quelldatei an den
Kompilierungsserver.

Im distcc-pump-Modus entpackt der Server den Satz aller Quelldateien in ein temporäres
Verzeichnis, das einen Verzeichnisbaum enthält, der den Teil des Dateisystems widerspiegelt, der
ist für die Vorverarbeitung relevant, einschließlich symbolischer Links.

Der Compiler wird dann von dem Pfad im temporären Verzeichnis ausgeführt, das der
aktuelles Arbeitsverzeichnis auf dem Client. Um die vielen Hundert Dateien zu finden und zu übertragen
die oft Teil einer einzelnen Zusammenstellung sind, verwendet der Pumpenmodus ein inkrementelles Include
Analysealgorithmus. Der Include-Server ist ein Python-Programm, das dies implementiert
Algorithmus. Der Befehl distcc-pump startet den Include-Server, sodass während des gesamten Builds
es kann include-Anfragen durch distcc-Befehle beantworten.

Der Include-Server verwendet eine statische Analyse der Makrosprache, um mit bedingten
Zusammenstellung und berechnet enthält. Es verwendet die Eigenschaft, dass, wenn eine gegebene Header-Datei
bereits auf Includes analysiert wurde, ist es nicht erforderlich, dies erneut zu tun, wenn alle Include
Optionen (-I's) bleiben unverändert (zusammen mit anderen Bedingungen).

Bei großen Builds werden Header-Dateien im Durchschnitt jeweils hunderte Male eingeschlossen. Mit
distcc-pump-Modus jede solche Datei wird nur ein paar Mal analysiert, vielleicht nur einmal, stattdessen
Hunderte Male vorverarbeitet werden. Außerdem ist jede Quell- oder Header-Datei jetzt
nur einmal komprimiert, da der Include-Server die komprimierten Dateien speichert. Als ein
Dadurch kann sich der Zeitaufwand für die Erstellung von Zusammenstellungen um eine Größenordnung verkürzen
über die Vorverarbeitung von plain distcc.

Da distcc im Pumpmodus in der Lage ist, Dateien bis zu zehnmal schneller herauszuschieben, baut
Die Geschwindigkeit kann bei großen Builds im Vergleich zum einfachen distcc-Modus um das Dreifache oder mehr erhöht werden.

RESTRICTIONS FÜR PUMP MODE

Die Verwendung des Pumpmodus erfordert, dass sowohl Client als auch Server Version 3.0 oder höher von distcc verwenden und
distccd (bzw.).

Die inkrementelle Include-Analyse des Distc-Pump-Modus beruht auf der Grundannahme
dass sich Quell- und Headerdateien während des Buildprozesses nicht ändern. Ein paar komplexe Builds
Systeme wie das für Linux-Kernel 2.6 erfüllen diese Anforderung nicht ganz. Zu
Überwindung solcher Probleme und anderer Eckfälle wie absolute Dateipfade in Includes, siehe
include_server(1) Man Seite.

Eine weitere wichtige Annahme ist, dass die Include-Konfiguration aller Maschinen
identisch. Daher müssen die Header unter dem Standardsystempfad auf allen Servern gleich sein
und alle Kunden. Wenn eine Standard-GNU-Compiler-Installation verwendet wird, gilt diese Anforderung
gilt für alle Bibliotheken, deren Header-Dateien installiert sind unter / usr / include or
/usr/local/include/. Beachten Sie, dass die Installation von Softwarepaketen oft zu zusätzlichen
headers-Dateien, die in Unterverzeichnissen von beiden platziert werden.

Wenn diese Annahme nicht zutrifft, ist es möglich, Builds mit distcc-pump zu unterbrechen
-Modus, oder schlimmer noch, um ohne Vorwarnung falsche Ergebnisse zu erhalten. Derzeit ist dieser Zustand nicht
überprüft, und es steht auf unserer TODO-Liste, um dieses Problem zu beheben.

Eine einfache Möglichkeit, um sicherzustellen, dass die Include-Konfigurationen identisch sind, ist die Verwendung eines Cross-
Compiler, der einen Standard-Systemsuchpfad definiert, der auf Verzeichnisse der
Compiler-Installation.

Siehe die include_server(1) Handbuch für weitere Informationen zu Symptomen und Ursachen von Verstößen
von distcc-Pumpenmodus-Annahmen.

zur Auswahl ZUSAMMENFASSUNG

Die meisten an distcc übergebenen Optionen werden als Compiler-Optionen interpretiert. Die folgenden Optionen
werden von distcc selbst verstanden. Wenn eine dieser Optionen angegeben ist, wird distcc nicht
den Compiler aufrufen.

--help Zeigt zusammenfassende Anweisungen an.

--Version
Zeigt die distcc-Clientversion an.

--show-hosts
Zeigt die Hostliste an, die distcc verwenden würde. Siehe den Abschnitt Hostspezifikationen.

--scan-beinhaltet
Zeigt die Liste der Dateien an, die distcc an den Remote-Rechner senden würde, als
vom Include-Server berechnet. Dies ist eine konservative (Über-)Annäherung der
Dateien, die vom C-Compiler gelesen werden. Diese Option funktioniert nur im Pumpenmodus.
Einzelheiten zur Berechnung finden Sie im Abschnitt "Funktionsweise des Distcc-Pump-Modus".

Die Listenausgabe von distcc --scan-beinhaltet enthält einen Eintrag pro Zeile. Jeder
line enthält eine Kategorie gefolgt von einem Pfad. Die Kategorie ist eine von DATEI, SYMLINK,
VERZEICHNIS oder SYSTEMVERZEICHNIS:

FILE gibt eine Quelldatei oder Header-Datei an, die an den distcc-Server gesendet würde
Gastgeber.

SYMLINK gibt einen symbolischen Link an, der an den distcc-Serverhost gesendet würde.

DIRECTORY gibt ein Verzeichnis an, das möglicherweise zum Kompilieren der Quelle benötigt wird
Datei. Zum Beispiel kann ein Verzeichnis "foo" wegen eines Includes der
form #include "foo/../bar.h". Solche Verzeichnisse würden auf der Distcc . erstellt
Server-Host.

SYSTEMVERZEICHNIS bezeichnet ein System-Include-Verzeichnis, dh ein Verzeichnis, das sich auf dem
Standard-Include-Pfad des Compilers, wie z./ usr / include"; solche Verzeichnisse sind
angenommen, auf dem distcc-Server-Host vorhanden zu sein, und würde daher nicht an den
distcc-Server-Host.

-j Zeigt den Parallelitätsgrad von distcc an, wie aus der Hostliste berechnet; es ist der
maximale Anzahl ausstehender Aufträge, die von diesem Client an alle Server ausgegeben werden. Von
Standardmäßig ist dies das Vierfache der Anzahl der Hosts in der Hostliste, es sei denn, die
Die Option /LIMIT wurde in der Hostliste verwendet. Siehe den Abschnitt Hostspezifikationen.

INSTALLIEREN DISTCC

Es gibt drei verschiedene Möglichkeiten, distcc aufzurufen, um verschiedenen Umständen gerecht zu werden:

distcc kann unter dem Namen des echten Compilers installiert werden, um Aufrufe an . abzufangen
es und führen Sie sie aus der Ferne aus. Dieser "maskierte" Compiler hat die größte Kompatibilität
mit bestehenden Quellbäumen und ist praktisch, wenn Sie distcc für alle verwenden möchten
Zusammenstellung. Die Tatsache, dass distcc verwendet wird, ist für die Makefiles transparent.

distcc kann Compiler-Befehlszeilen vorangestellt werden, z. B. "distcc cc -c hello.c"
oder CC="distcc gcc". Dies ist praktisch, wenn Sie distcc nur für einige verwenden möchten
Zusammenstellungen oder zum Ausprobieren, kann aber bei einigen Makefiles zu Problemen führen oder
Versionen von libtool, die davon ausgehen, dass $CC kein Leerzeichen enthält.

Schließlich kann distcc direkt als Compiler verwendet werden. "cc" wird immer als verwendet
Name des echten Compilers in diesem "impliziten" Modus. Das kann praktisch sein für
interaktive Nutzung, wenn der "explizite" Modus nicht funktioniert, aber nicht wirklich empfohlen wird
für neue Verwendung.

Denken Sie daran, dass Sie nicht zwei Methoden zum gleichzeitigen Aufrufen von distcc verwenden sollten. wenn du
verwenden ein Maskerade-Verzeichnis, ändern Sie CC und/oder CXX nicht, legen Sie das Verzeichnis einfach früher ab
auf deinem WEG. Wenn Sie kein Maskerade-Verzeichnis verwenden, müssen Sie entweder CC . ändern
und/oder CXX, oder modifizieren Sie die Makefile(s), um distcc explizit aufzurufen.

Maskieren

Die Grundidee besteht darin, ein "Maskerade-Verzeichnis" zu erstellen, das Links vom Namen von . enthält
den echten Compiler in die distcc-Binärdatei. Dieses Verzeichnis wird früh im PATH eingefügt, also
dass Aufrufe des Compilers abgefangen werden und stattdessen distcc ausgeführt wird. distcc entfernt dann
sich selbst aus dem PATH, um den echten Compiler zu finden.

Beispielsweise:

# mkdir /usr/lib/distcc/bin
# cd /usr/lib/distcc/bin
# ln -s ../../../bin/distcc gcc
# ln -s ../../../bin/distcc cc
# ln -s ../../../bin/distcc g++
# ln -s ../../../bin/distcc c++

Um distcc zu verwenden, muss ein Benutzer dann nur das Verzeichnis /usr/lib/distcc/bin früh in
den PATH und haben eine Hostliste in DISTCC_HOSTS oder eine Datei gesetzt. distcc wird die
Ruhe.

Beachten Sie, dass dieses Maskerade-Verzeichnis im PATH vor dem Verzeichnis stehen muss, das
enthält die eigentlichen Compiler gleichen Namens und alle Hilfsprogramme, die
diese Compiler-Aufrufe (wie as oder ld) müssen auch auf dem PATH in einem Verzeichnis zu finden sein
nach dem Masquerade-Verzeichnis, da distcc den echten Compiler mit einem PATH aufruft
Wert, bei dem alle Verzeichnisse bis einschließlich des Maskerade-Verzeichnisses abgeschnitten sind.

Es ist möglich, im Maskerade-Modus einen "Rekursionsfehler" zu erhalten, was bedeutet, dass distcc
findet sich irgendwie wieder, nicht der eigentliche Compiler. Dies kann darauf hinweisen, dass Sie zwei haben
maskieren Sie Verzeichnisse auf dem PATH, möglicherweise weil zwei distcc-Installationen in
verschiedene Orte. Es kann auch darauf hindeuten, dass Sie versuchen, "vermummt" und zu mischen
"explizite" Operation.

Rekursionsfehler können vermieden werden, indem Shell-Skripte anstelle von Links verwendet werden. Zum Beispiel in
/usr/lib/distcc/bin erstellt eine Datei cc, die Folgendes enthält:

#!/ Bin / sh
distcc /usr/bin/gcc "$@"

Auf diese Weise sind wir nicht darauf angewiesen, dass distcc den echten gcc durch Nachforschungen lokalisieren muss
die PATH-Variable. Stattdessen wird der Compilerspeicherort explizit angegeben.

VERWENDUNG DISTCC MIT CCACH

ccache ist ein Programm, das Software-Builds beschleunigt, indem es die Ergebnisse von Kompilierungen zwischenspeichert.
ccache wird normalerweise vor distcc aufgerufen, damit Ergebnisse von einem normalen abgerufen werden
Zwischenspeicher. Möglicherweise sind einige Experimente erforderlich, damit idiosynkratische Makefiles erstellt werden können
alles funktioniert zusammen.

Die zuverlässigste Methode ist die Einstellung

CCACHE_PREFIX="distcc"

Dies weist ccache an, distcc als Wrapper um den echten Compiler auszuführen. CCache verwendet immer noch
der echte Compiler, um Compiler-Upgrades zu erkennen.

ccache kann dann entweder mit einem Maskerade-Verzeichnis ausgeführt werden or indem man es einstellt

CC="ccache gcc"

Ab Version 2.2 speichert ccache die Kompilierung von vorverarbeiteten Quellen nicht im Cache und wird dies auch tun
Bekomme nie einen Cache-Treffer, wenn es von distccd oder distcc ausgeführt wird. Es darf nur auf dem
clientseitig und vor distcc zu verwenden.

Der Pumpmodus von distcc ist nicht mit ccache kompatibel.

HOST SPEZIFIKATIONEN

Eine "Hostliste" teilt distcc mit, welche Maschinen für die Kompilierung verwendet werden sollen. In Ordnung, distcc sieht aus
der $DISTCC_HOSTS Umgebungsvariable, die des Benutzers $DISTCC_DIR/hosts Datei und die
systemweite Hostdatei. Wenn keine Hostliste gefunden werden kann, gibt distcc eine Warnung aus und kompiliert
örtlich.

Die Hostliste ist eine einfache durch Leerzeichen getrennte Liste von Hostspezifikationen. Das einfachste
und die gebräuchlichste Form ist ein Hostname, wie z

localhost roten grünen blau

distcc bevorzugt Hosts am Anfang der Liste, daher sollten Maschinen in der Liste aufgeführt werden
absteigende Geschwindigkeitsreihenfolge. Insbesondere wenn nur eine einzelne Kompilierung ausgeführt werden kann (wie z
wie aus einem Konfigurationsskript), wird die erste aufgeführte Maschine verwendet (aber siehe - randomisieren unten).

Erteilung localhost an der richtigen Stelle in der Liste ist wichtig, um eine gute Leistung zu erzielen.
Da der Overhead für die lokale Ausführung von Jobs gering ist, sollte localhost normalerweise an erster Stelle stehen.
Es ist jedoch wichtig, dass dem Client genügend Zyklen zur Verfügung stehen, um die lokalen Jobs auszuführen und
der distcc-Client. Wenn der Klient langsamer ist als die Freiwilligen oder wenn es viele sind
Freiwillige, dann sollte der Kunde später in die Liste aufgenommen werden oder gar nicht. Als General
Regel, wenn die aggregierte CPU-Geschwindigkeit des Clients weniger als ein Fünftel der Gesamtgeschwindigkeit beträgt, dann
Der Kunde sollte aus der Liste gestrichen werden.

Wenn Sie einen großen gemeinsam genutzten Build-Cluster und eine einzelne gemeinsam genutzte Hosts-Datei haben, gelten die oben genannten Regeln
würde dazu führen, dass die ersten Maschinen in der Hosts-Datei zuerst ausprobiert werden, obwohl sie
sind wahrscheinlich mehr beschäftigt als Maschinen weiter hinten in der Liste. Um dies zu vermeiden, platzieren Sie das Schlüsselwort
- randomisieren in die Gastgeberliste. Dadurch wird die Hostliste randomisiert, was
sollte die Leistung für große Build-Cluster leicht verbessern.

Es gibt zwei spezielle Hostnamen --localslots und --localslots_cpp die nützlich sind für
Anpassen der Last auf der lokalen Maschine. Die --localslots host gibt an, wie viele Jobs das
kann nicht remote ausgeführt werden, die gleichzeitig auf dem lokalen Computer ausgeführt werden kann, während
--localslots_cpp steuert, wie viele Präprozessoren parallel auf dem lokalen . laufen
Maschine. Die Optimierung dieser Werte kann die Leistung verbessern. Das Verlinken bei großen Projekten kann dauern
große Speichermengen. Ausführen von parallelen Linkern, die nicht remote ausgeführt werden können,
kann das Wechseln der Maschine erzwingen, was die Leistung verringert, wenn nur die Jobs ausgeführt werden
Sequenz ohne zu tauschen. Die Anzahl der parallelen Präprozessoren genau richtig einstellen
ermöglicht es Ihnen, größere Parallelfaktoren mit make zu verwenden, da die lokale Maschine jetzt einige hat
Mechanismen zur Messung des lokalen Ressourcenverbrauchs.

Endlich gibt es den Host-Eintrag

Die Leistung hängt von den Details des Quellcodes und der Makefiles ab, die für das Projekt verwendet werden, und
die Maschinen- und Netzwerkgeschwindigkeit. Experimentieren mit verschiedenen Einstellungen für die Hostliste
und -j Faktor kann die Leistung verbessern.

Die Syntax lautet

DISTCC_HOSTS = HOSTSPEC ...
HOSTSPEC = LOCAL_HOST | SSH_HOST | TCP_HOST | OLDSTYLE_TCP_HOST
| GLOBAL_OPTION
| ZEROKONF
LOCAL_HOST = lokaler Host[/LIMIT]
| --localslots=
| --localslots_cpp=
SSH_HOST = [USER]@HOSTID[/LIMIT][:COMMAND][OPTIONEN]
TCP_HOST = HOSTID[:PORT][/LIMIT][OPTIONEN]
OLDSTYLE_TCP_HOST = HOSTID[/LIMIT][:PORT][OPTIONEN]
HOSTID = HOSTNAME | IPV4 | IPv6
OPTIONEN = ,OPTION[OPTIONEN]
OPTION = lzo | cpp
GLOBAL_OPTION = --randomize
ZEROCONF = +zeroconf

Hier einige einzelne Beispiele für die Syntax:

localhost
Das wörtliche Wort "localhost" wird speziell interpretiert, um zu bewirken, dass Zusammenstellungen
direkt ausgeführt, anstatt an einen Daemon auf dem lokalen Rechner weitergegeben zu werden. Wenn Sie tun
zum Testen eine Verbindung zu einem Daemon auf dem lokalen Computer herstellen möchten, dann geben Sie die
die IP-Adresse oder den echten Hostnamen der Maschine. (Das wird langsamer.)

IPV6 Eine wörtliche IPv6-Adresse in eckigen Klammern, wie z [::1]

IPV4 Eine wörtliche IPv4-Adresse, wie z 10.0.0.1

HOSTNAME
Ein Hostname, der mit dem Resolver nachgeschlagen werden soll.

:HAFEN Stellen Sie eine Verbindung zu einer angegebenen dezimalen Portnummer anstelle des Standardwerts 3632 her.

@HOSTID
Stellen Sie über SSH statt über TCP eine Verbindung zum Host her. Optionen für die SSH-Verbindung können
eingestellt werden, in ~ / .ssh / Konfig

BENUTZER@ Verbinden Sie sich über SSH mit dem angegebenen Benutzernamen.

:BEFEHL
Stellen Sie eine Verbindung über SSH her und verwenden Sie einen angegebenen Pfad, um den distccd-Server zu finden. Das ist
normalerweise nur erforderlich, wenn Sie distccd aus irgendeinem Grund nicht in ein Verzeichnis installieren können
auf dem Standardpfad für SSH-Verbindungen. Verwenden Sie dies, wenn Sie Fehler wie "distccd:
Befehl nicht gefunden" im SSH-Modus.

/GRENZE Jeder Hostspezifikation kann eine Dezimalgrenze hinzugefügt werden, um die Anzahl der
Aufträge, die dieser Client an die Maschine sendet. Das Limit ist standardmäßig auf vier pro
host (zwei für localhost), kann aber vom Server weiter eingeschränkt werden. Du solltest
Diese muss nur bei Servern mit mehr als zwei Prozessoren erhöht werden.

, lzo Aktiviert die LZO-Komprimierung für diesen TCP- oder SSH-Host.

, cpp Aktiviert den distcc-Pump-Modus für diesen Host. Hinweis: Der build-Befehl muss in eingeschlossen werden
das Skript distcc-pump, um den Include-Server zu starten.

- randomisieren
Ordnen Sie die Reihenfolge der Hostliste vor der Ausführung zufällig an.

+zeroconf
Dieser zu erhalten is einzige verfügbar if distcc wurde kompiliert mit avahi Support freigegeben at
konfigurieren Zeit. Wenn dieser spezielle Eintrag in der Hosts-Liste vorhanden ist, wird distcc
Verwenden Sie Avahi Zeroconf DNS Service Discovery (DNS-SD), um alle verfügbaren Distccds zu finden
Server im lokalen Netzwerk. Dadurch entfällt die Notwendigkeit, den Host explizit aufzulisten
Namen oder IP-Adressen der distcc-Servermaschinen. Die distccd-Server müssen über
wurde mit der Option "--zeroconf" in distccd gestartet. Ein wichtiger Vorbehalt ist das
In der aktuellen Implementierung werden Pumpmodus (",cpp") und Kompression (",lzo")
niemals für Hosts verwendet werden, die über zeroconf lokalisiert werden.

Hier ein Beispiel, das einige Möglichkeiten aufzeigt:

localhost/2 @bigman/16:/opt/bin/distccd alte Maschine: 4200/1
# cartman is nach unten
entfernt/3,lzo

Kommentare sind in Hostspezifikationen erlaubt. Kommentare beginnen mit einem Raute-/Pfund-Zeichen (#)
und bis zum Ende der Zeile laufen.

Wenn ein Host in der Liste nicht erreichbar ist, gibt distcc eine Warnung aus und ignoriert diesen Host für
etwa eine Minute.

KOMPRESSION

Das lzo host-Option gibt an, dass die LZO-Komprimierung für die Datenübertragung verwendet werden soll,
einschließlich vorverarbeiteter Quell-, Objektcode- und Fehlermeldungen. Kompression ist normalerweise
sparsam in Netzwerken mit weniger als 100 Mbit/s, aber die Ergebnisse können je nach Netzwerk variieren,
Prozessoren und Quellbaum.

Durch Aktivieren der Komprimierung verbrauchen der distcc-Client und -Server mehr CPU-Zeit, aber weniger
Netzwerktraffic. Für den Pumpenbetrieb ist die zusätzliche CPU-Zeit unerheblich. Die Kompression
Das Verhältnis beträgt normalerweise 4:1 für den Quellcode und 2:1 für den Objektcode.

Die Verwendung der Komprimierung erfordert, dass sowohl Client als auch Server mindestens Version 2.9 von distcc verwenden.
Es ist keine Serverkonfiguration erforderlich: Der Server antwortet immer mit komprimierten Antworten auf
komprimierte Anfragen.

Der Pumpmodus erfordert, dass die Server die Option lzo host aktiviert haben.

SUCHE PFADE

Wenn der Compilername ein absoluter Pfad ist, wird er wörtlich an den Server übergeben und die
Compiler wird von diesem Verzeichnis ausgeführt. Zum Beispiel:

distcc /usr/local/bin/gcc-3.1415 -c Hallo c

Wenn der Compilername nicht absolut oder nicht vollständig qualifiziert ist, wird der PATH von distccd durchsucht.
Wenn distcc von einem Maskerade-Verzeichnis ausgeführt wird, ist nur der Basisname des Compilers
Gebraucht. Der PATH des Clients wird nur zum Ausführen des Präprozessors verwendet und hat keine Auswirkungen auf die
Pfad des Servers.

AUSZEITEN

Sowohl der distcc-Client als auch der Server legen Zeitüberschreitungen bei der Datenübertragung über das Netzwerk fest.
Dies soll Hosts erkennen, die ausgefallen oder nicht erreichbar sind, und Kompilierungen verhindern
hängt auf unbestimmte Zeit, wenn ein Server während des Betriebs getrennt wird. Wenn ein clientseitiges Timeout
abläuft, wird der Job lokal erneut ausgeführt.

Die Timeouts sind derzeit nicht konfigurierbar.

DIAGNOSE

Fehlermeldungen oder Warnungen von lokalen oder entfernten Compilern werden an die Diagnose weitergegeben
Ausgabe auf dem Client.

distcc kann umfangreiche Debugging-Informationen liefern, wenn die Option verbose verwendet wird. Dies
wird durch die kontrollierte DISTCC_VERBOSE Umgebungsvariable auf dem Client und die - ausführlich
Option auf dem Server. Untersuchen Sie zur Fehlerbehebung sowohl den Client- als auch den Serverfehler
Nachrichten.

EXIT CODES

Der Exit-Code von distcc ist normalerweise der des Compilers: Null für erfolgreiche Kompilierung
und sonst ungleich Null.

distcc unterscheidet zwischen "echten" Fehlern wie einem Syntaxfehler in der Quelle und
"versehentliche" Fehler wie ein Netzwerkproblem bei der Verbindung zu einem Freiwilligen. Im Falle
von versehentlichen Fehlern wird distcc die Kompilierung lokal wiederholen, es sei denn, der DISTCC_FALLBACK
Option wurde deaktiviert.

Wenn der Compiler mit einem Signal beendet wird, gibt distcc einen Exit-Code von 128 plus das Signal zurück
Anzahl.

distcc-interne Fehler verursachen einen Exit-Code zwischen 100 und 127. Insbesondere

100 Allgemeiner distcc-Fehler.

101 schlechte Argumente.

102 Bindung fehlgeschlagen.

103 Verbindung fehlgeschlagen.

104 Compiler abgestürzt.

105 Kein Speicher mehr.

106 Fehlerhafte Host-SPEC

107 E/A-Fehler

108 Abgeschnitten.

109 Protokollfehler.

110 Der angegebene Compiler wurde auf dem Remote-Host nicht gefunden. Überprüfen Sie, ob $CC eingestellt ist
ordnungsgemäß und dass es in einem Verzeichnis im Suchpfad für . installiert ist
distccd.

111 Rekursiver Aufruf an distcc.

112 Fehler beim Verwerfen der Berechtigungen.

113 Netzwerkzugriff verweigert.

114 Wird von einem anderen Prozess verwendet.

115 Keine solche Datei.

116 Keine Hosts definiert und Fallbacks deaktiviert.

118 Zeitüberschreitung.

Verwenden Sie distcc online mit den onworks.net-Diensten