distcc - En ligne dans le Cloud

PROGRAMME:

Nom

distcc - compilateur distribué C/C++/ObjC avec extensions distcc-pump

SYNOPSIS

distcc [COMPILATEUR CHOIX]

distcc [COMPILATEUR CHOIX]

[COMPILATEUR CHOIX]

distcc [DISTCC CHOIX]

DESCRIPTION

distcc distribue la compilation de code C sur plusieurs machines d'un réseau. distcc
devrait toujours générer les mêmes résultats qu'une compilation locale, il est simple à installer et
utiliser, et c'est souvent beaucoup plus rapide qu'une compilation locale.

Cette version intègre un distcc simple ainsi qu'une amélioration appelée mode pompe ou
distcc-pompe.

Pour chaque tâche, distcc en mode clair envoie le code source complet prétraité et
arguments du compilateur à travers le réseau du client à un serveur de compilation. En pompe
mode, distcc envoie le code source et les fichiers d'en-tête inclus de manière récursive (à l'exclusion de ceux
à partir des répertoires d'en-tête du système par défaut), de sorte que le prétraitement et la compilation
peut avoir lieu sur les serveurs de compilation. Cela accélère la livraison des compilations en
jusqu'à un ordre de grandeur sur la plaine distcc.

La compilation est pilotée par une machine cliente, qui est généralement le poste de travail du développeur
ou ordinateur portable. Le client distcc s'exécute sur cette machine, tout comme make, le préprocesseur (si
le mode de pompage de distcc n'est pas utilisé), l'éditeur de liens et d'autres étapes du processus de génération. Tout
nombre de machines volontaires agissent comme des serveurs de compilation et aident le client à construire le
programme, en exécutant le distccd(1) démon, compilateur C et assembleur selon les besoins.

distcc peut s'exécuter sur des sockets TCP (sur le port 3632 par défaut), ou via un tunnel
commande telle que ssh(1). Pour les connexions TCP, les volontaires doivent exécuter le distccd(1) démon
soit directement, soit à partir d'inetd. Pour les connexions SSH, distccd doit être installé mais doit
ne sauraient être à l'écoute des connexions.

Les connexions TCP ne doivent être utilisées que sur des réseaux sécurisés car il n'y a pas d'utilisateur
l'authentification ou la protection du code source ou objet. Les connexions SSH sont généralement de 25%
plus lent en raison de la surcharge du processeur pour le chiffrement, bien que cela puisse varier considérablement
en fonction des processeurs, du réseau et du programme en cours de construction.

distcc est destiné à être utilisé avec GNU Make -j option, qui exécute plusieurs compilateurs
processus simultanément. distcc répartit les travaux sur les processeurs locaux et distants.
Étant donné que distcc est capable de répartir la plupart du travail sur le réseau, un
niveau de concurrence peut être utilisé que pour les builds locaux. En règle générale, le -j Plus-value
doit être défini sur environ deux fois le nombre total de processeurs de serveur disponibles, mais sous réserve de
limites des clients. Ce paramètre permet un entrelacement maximal des tâches bloquées
en attente d'E/S disque ou réseau. Notez que distcc peut également fonctionner avec d'autres contrôles de construction
outils, tels que SCons, où des paramètres de simultanéité similaires doivent être ajustés.

La -j réglage, en particulier pour les grandes valeurs de -j, doit tenir compte de la charge CPU sur
le client. Des mesures supplémentaires peuvent être nécessaires pour réduire la charge client. Par exemple,
les liaisons simultanées doivent être sévèrement réduites à l'aide de verrous auxiliaires. L'effet de
d'autres activités de génération, telles que la compilation Java lors de la création de code mixte, doivent être
pris en considération. Les --localslots_cpp est défini par défaut sur 16. Cela limite le
nombre de processus simultanés qui effectuent le prétraitement en mode distcc simple (sans pompe).
Par conséquent, plus grand -j des valeurs supérieures à 16 peuvent être utilisées sans surcharger un client monoprocesseur
en raison du prétraitement. Des valeurs aussi élevées peuvent accélérer des parties de la construction qui ne
impliquent des compilations C, mais elles peuvent ne pas être utiles pour distinguer l'efficacité en mode clair.

En revanche, en utilisant le mode pompe et disons 40 serveurs, un réglage de -j80 ou plus grand peut être
approprié même pour les clients mono-processeur.

Il est fortement recommandé d'installer la même version du compilateur sur toutes les machines
participer à une construction. Des compilateurs incompatibles peuvent provoquer une compilation ou un lien mystérieux
les échecs.

PRISE EN MAIN RAPIDE

1 Pour chaque machine, téléchargez distcc, décompressez et installez.

2 Sur chacun des serveurs, exécutez distccd --démon avec --Autoriser options pour restreindre
accéder.

3 Mettez les noms des serveurs dans votre environnement :
$ export DISTCC_HOSTS='localhost rouge vert bleu'

4 Construisez !
$ make -j8 CC=distcc

PRISE EN MAIN RAPIDE POUR DISTCC-POMPE MODE

Procédez comme ci-dessus, mais à l'étape 3, spécifiez que les hôtes distants doivent assumer la charge de
prétraitement et que les fichiers envoyés sur le réseau doivent être compressés :

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

La --randomiser L'option impose une utilisation uniforme des serveurs de compilation. Alors que vous obtiendrez
certains bénéficient du mode pompe de distcc avec seulement quelques serveurs, vous obtenez des avantages croissants
avec plus de processeurs de serveur (jusqu'à des centaines !). Enveloppez votre build dans la commande pump,
ici en supposant 10 serveurs :

$ distcc-pompe make -j20 CC=distcc

COMMENT PLAINE (SANS POMPE) DISTCC TRAVAUX

distcc n'exécute le compilateur et l'assembleur qu'à distance. Avec un distcc simple, le
le préprocesseur doit toujours s'exécuter localement car il doit accéder à divers fichiers d'en-tête sur
la machine locale qui peut ne pas être présente, ou ne pas être la même, sur le volontaire. Les
L'éditeur de liens doit également examiner les bibliothèques et les fichiers objets, et doit donc s'exécuter localement.

Le compilateur et l'assembleur ne prennent qu'un seul fichier d'entrée (la source prétraitée) et
produire une seule sortie (le fichier objet). distcc expédie ces deux fichiers à travers le
réseau et peut donc exécuter le compilateur/assembleur à distance.

Heureusement, pour la plupart des programmes exécutant le préprocesseur est relativement bon marché, et le
linker est appelé relativement peu fréquent, donc la plupart du travail peut être distribué.

distcc examine sa ligne de commande pour déterminer laquelle de ces phases est invoquée, et
si le travail peut être distribué.

COMMENT DISTCC-POMPE MODE TRAVAUX

En mode pompe, distcc exécute également le préprocesseur à distance. Pour ce faire, le préprocesseur doit
avoir accès à tous les fichiers auxquels il aurait accédé s'il avait été exécuté localement. Dans
en mode pompe, par conséquent, distcc rassemble tous les en-têtes inclus de manière récursive, à l'exception du
ceux qui sont des en-têtes système par défaut, et les envoie avec le fichier source au
serveur de compilation.

En mode distcc-pump, le serveur décompresse l'ensemble de tous les fichiers sources dans un
répertoire, qui contient une arborescence de répertoires qui reflète la partie du système de fichiers qui
est pertinent pour le prétraitement, y compris les liens symboliques.

Le compilateur est alors exécuté à partir du chemin du répertoire temporaire qui correspond au
répertoire de travail courant sur le client. Pour trouver et transmettre les centaines de fichiers
qui font souvent partie d'une seule compilation, le mode pompe utilise une inclusion incrémentielle
algorithme d'analyse. Le serveur include est un programme Python qui implémente ce
algorithme. La commande distcc-pump démarre le serveur d'inclusion de sorte que tout au long de la construction
il peut répondre aux requêtes d'inclusion par les commandes distcc.

Le serveur d'inclusion utilise une analyse statique du langage macro pour gérer les conditions
compilation et calcul inclut. Il utilise la propriété que lorsqu'un fichier d'en-tête donné a
déjà été analysé pour les inclusions, il n'est pas nécessaire de le refaire si toutes les inclusions
les options (-I) sont inchangées (ainsi que d'autres conditions).

Pour les builds volumineux, les fichiers d'en-tête sont inclus, en moyenne, des centaines de fois chacun. Avec
mode distcc-pump, chaque fichier de ce type n'est analysé que quelques fois, peut-être une seule fois, à la place
d'être prétraités des centaines de fois. De plus, chaque fichier source ou d'en-tête est maintenant
compressé une seule fois, car le serveur d'inclusion mémorise les fichiers compressés. Comme un
résultat, le temps consacré à la préparation des compilations peut chuter jusqu'à un ordre de grandeur
sur le prétraitement de plain distcc.

Parce que distcc en mode pompe est capable de sortir des fichiers jusqu'à environ dix fois plus vite, construisez
la vitesse peut augmenter de 3X ou plus pour les gros builds par rapport au mode distcc simple.

RESTRICTIONS POUR POMPE MODE

L'utilisation du mode pompe nécessite que le client et les serveurs utilisent la version 3.0 ou ultérieure de distcc et
distccd (respectivement).

L'analyse incrémentielle d'inclusion du mode pompe à disque repose sur l'hypothèse fondamentale
que les fichiers source et d'en-tête ne changent pas pendant le processus de génération. Quelques constructions complexes
les systèmes, comme celui du noyau Linux 2.6, ne satisfont pas tout à fait à cette exigence. À
surmonter ces problèmes, et d'autres cas de coin tels que les chemins de fichiers absolus dans les inclusions, voir
le inclure_serveur(1) page de manuel.

Une autre hypothèse importante est que la configuration d'inclusion de toutes les machines doit être
identique. Ainsi, les en-têtes sous le chemin système par défaut doivent être les mêmes sur tous les serveurs
et tous les clients. Si une installation de compilateur GNU standard est utilisée, alors cette exigence
s'applique à toutes les bibliothèques dont les fichiers d'en-tête sont installés sous / usr / include or
/usr/local/include/. Notez que l'installation de progiciels entraîne souvent des
les fichiers d'en-têtes étant placés dans des sous-répertoires de l'un ou l'autre.

Si cette hypothèse ne tient pas, alors il est possible de casser les builds avec distcc-pump
mode, ou pire, pour obtenir des résultats erronés sans avertissement. Actuellement, cette condition n'est pas
vérifié, et il est sur notre liste TODO pour résoudre ce problème.

Un moyen simple de garantir que les configurations d'inclusion sont identiques consiste à utiliser une
compilateur qui définit un chemin de recherche système par défaut limité aux répertoires du
l'installation du compilateur.

Voir le inclure_serveur(1) manuel pour plus d'informations sur les symptômes et les causes des violations
des hypothèses de mode distcc-pump.

OPTION RÉSUMÉ

La plupart des options passées à distcc sont interprétées comme des options du compilateur. Les options suivantes
sont compris par distcc lui-même. Si l'une de ces options est spécifiée, distcc ne
invoquer le compilateur.

--Aidez-moi Affiche des instructions récapitulatives.

--version
Affiche la version du client distcc.

--show-hôtes
Affiche la liste d'hôtes que distcc utiliserait. Voir la section Spécifications de l'hôte.

--scan-inclut
Affiche la liste des fichiers que distcc enverrait à la machine distante, comme
calculé par le serveur d'inclusion. Il s'agit d'une (sur-)approximation conservatrice de la
fichiers qui seraient lus par le compilateur C. Cette option ne fonctionne qu'en mode pompe.
Voir la section "Comment fonctionne le mode Distcc-pump" pour plus de détails sur la façon dont cela est calculé.

La liste sortie par distcc --scan-inclut contiendra une entrée par ligne. Chaque
La ligne contient une catégorie suivie d'un chemin. La catégorie est l'une de FICHIER, SYMLINK,
DIRECTORY, ou SYSTEMDIR :

DOSSIER indique un fichier source ou un fichier d'en-tête qui serait envoyé au serveur distcc
hôte.

LIEN SYM indique un lien symbolique qui serait envoyé à l'hôte du serveur distcc.

ANNUAIRE indique un répertoire qui peut être nécessaire pour compiler la source
déposer. Par exemple, un répertoire "foo" peut être nécessaire à cause d'une inclusion du
forme #include "foo/../bar.h". De tels répertoires seraient créés sur le distcc
hôte du serveur.

RÉPSYSTÈME indique un répertoire d'inclusion système, c'est-à-dire un répertoire qui se trouve sur le
chemin d'inclusion par défaut du compilateur, tel que "/ usr / include"; ces répertoires sont
supposé être présent sur l'hôte du serveur distcc et ne serait donc pas envoyé au
hôte du serveur distcc.

-j Affiche le niveau de concurrence de distcc, tel que calculé à partir de la liste d'hôtes ; c'est le
nombre maximal de travaux en attente émis par ce client vers tous les serveurs. Par
par défaut, ce sera quatre fois le nombre d'hôtes dans la liste d'hôtes, à moins que le
L'option /LIMIT a été utilisée dans la liste des hôtes. Voir la section Spécifications de l'hôte.

INSTALLATION DISTCC

Il existe trois manières différentes d'appeler distcc, selon les circonstances :

distcc peut être installé sous le nom du vrai compilateur, pour intercepter les appels à
et exécutez-les à distance. Ce compilateur "masqué" a la compatibilité la plus large
avec les arborescences de sources existantes, et est pratique lorsque vous souhaitez utiliser distcc pour tous
compilation. Le fait que distcc soit utilisé est transparent pour les makefiles.

distcc peut être ajouté aux lignes de commande du compilateur, telles que "distcc cc -c hello.c"
ou CC="distcc gcc". Ceci est pratique lorsque vous souhaitez utiliser distcc pour certains
compilations ou pour l'essayer, mais peut causer des problèmes avec certains makefiles ou
versions de libtool qui supposent que $CC ne contient pas d'espace.

Enfin, distcc peut être utilisé directement comme compilateur. "cc" est toujours utilisé comme
nom du vrai compilateur dans ce mode "implicite". Cela peut être pratique pour
utilisation interactive lorsque le mode "explicite" ne fonctionne pas mais n'est pas vraiment recommandé
pour un nouvel usage.

N'oubliez pas que vous ne devez pas utiliser deux méthodes pour appeler distcc en même temps. Si tu
utilisez un répertoire de mascarade, ne changez pas CC et/ou CXX, placez simplement le répertoire tôt
sur votre CHEMIN. Si vous n'utilisez pas de répertoire de mascarade, vous devrez soit changer CC
et/ou CXX, ou modifiez le(s) makefile(s) pour appeler explicitement distcc.

MASQUERADING

L'idée de base est de créer un "répertoire mascarade" qui contient des liens du nom de
le vrai compilateur du binaire distcc. Ce répertoire est inséré au début du PATH, donc
que les appels au compilateur sont interceptés et que distcc est exécuté à la place. distcc supprime ensuite
lui-même du PATH pour trouver le vrai compilateur.

Par exemple :

# 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++

Ensuite, pour utiliser distcc, un utilisateur a juste besoin de mettre le répertoire /usr/lib/distcc/bin au début
le PATH et avoir défini une liste d'hôtes dans DISTCC_HOSTS ou un fichier. distcc gérera le
reste.

Notez que ce répertoire de mascarade doit apparaître sur le PATH avant le répertoire qui
contient les compilateurs réels du même nom, et que tous les programmes auxiliaires qui
ces appels de compilateurs (tels que ou ld) doivent également être trouvés sur le PATH dans un répertoire
après le répertoire de mascarade puisque distcc appelle le vrai compilateur avec un PATH
valeur qui a supprimé tous les répertoires jusqu'au répertoire de mascarade inclus.

Il est possible d'obtenir une "erreur de récursivité" en mode mascarade, ce qui signifie que distcc est
se retrouver en quelque sorte à nouveau, pas le vrai compilateur. Cela peut indiquer que vous avez deux
mascarade répertoires sur le PATH, peut-être à cause d'avoir deux installations distcc dans
différents endroits. Cela peut également indiquer que vous essayez de mélanger « masqués » et
opération "explicite".

Les erreurs de récursivité peuvent être évitées en utilisant des scripts shell au lieu de liens. Par exemple, dans
/usr/lib/distcc/bin crée un fichier cc qui contient :

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

De cette façon, nous ne dépendons pas du fait que distcc doive localiser le vrai gcc en enquêtant
la variable CHEMIN. Au lieu de cela, l'emplacement du compilateur est explicitement fourni.

EN UTILISANT DISTCC WITH CCACHE

ccache est un programme qui accélère la construction de logiciels en mettant en cache les résultats des compilations.
ccache est normalement appelé avant distcc, de sorte que les résultats sont récupérés à partir d'un
cache. Certaines expérimentations peuvent être nécessaires pour que les makefiles idiosyncratiques
tout fonctionne ensemble.

La méthode la plus fiable consiste à définir

CCACHE_PREFIX="distcc"

Cela indique à ccache d'exécuter distcc en tant que wrapper autour du vrai compilateur. ccache utilise toujours
le vrai compilateur pour détecter les mises à jour du compilateur.

ccache peut alors être exécuté en utilisant soit un répertoire de mascarade or en mettant

CC="ccache gcc"

Depuis la version 2.2, ccache ne met pas en cache la compilation à partir de la source prétraitée et le fera donc
n'obtenez jamais d'accès au cache s'il est exécuté à partir de distccd ou distcc. Il doit être exécuté uniquement sur le
côté client et avant distcc pour toute utilisation.

Le mode pompe de distcc n'est pas compatible avec ccache.

HÔTE DONNÉES TECHNIQUES

Une "liste d'hôtes" indique à distcc quelles machines utiliser pour la compilation. Dans l'ordre, distcc regarde
dans l' $DISTCC_HOSTS variable d'environnement, l'utilisateur $DISTCC_DIR/hôtes fichier et
fichier hôte à l'échelle du système. Si aucune liste d'hôtes ne peut être trouvée, distcc émet un avertissement et compile
localement.

La liste d'hôtes est une simple liste de spécifications d'hôtes séparées par des espaces. Le plus simple
et la forme la plus courante est un nom d'hôte, tel que

localhost rouge et une transition qui soit juste. Bleu

distcc préfère les hôtes vers le début de la liste, les machines doivent donc être répertoriées dans
ordre décroissant de vitesse. En particulier, lorsqu'une seule compilation peut être exécutée (comme
à partir d'un script de configuration), la première machine répertoriée est utilisée (mais voir --randomiser ci-dessous).

Placement localhost au bon endroit dans la liste est important pour obtenir de bonnes performances.
Étant donné que la surcharge pour l'exécution des tâches localement est faible, localhost devrait normalement être le premier.
Cependant, il est important que le client dispose de suffisamment de cycles libres pour exécuter les tâches locales et
le client distcc. Si le client est plus lent que les volontaires, ou s'il y a beaucoup
volontaires, le client doit être mis plus tard dans la liste ou pas du tout. En général
règle, si la vitesse globale du processeur du client est inférieure à un cinquième du total, alors
le client doit être exclu de la liste.

Si vous avez un grand cluster de build partagé et un seul fichier d'hôtes partagé, les règles ci-dessus
provoquerait l'essai des premières machines du fichier hosts, même si elles
sont susceptibles d'être plus occupés que les machines situées plus loin dans la liste. Pour éviter cela, placez le mot-clé
--randomiser dans la liste des hôtes. Cela entraînera la randomisation de la liste d'hôtes, ce qui
devrait améliorer légèrement les performances pour les grands clusters de build.

Il y a deux noms d'hôtes spéciaux --emplacements locaux ainsi que --localslots_cpp qui sont utiles pour
ajuster la charge sur la machine locale. Les --emplacements locaux l'hôte spécifie le nombre de travaux qui
ne peut pas être exécuté à distance qui peut être exécuté simultanément sur la machine locale, tandis que
--localslots_cpp contrôle le nombre de préprocesseurs exécutés en parallèle sur le local
machine. Le réglage de ces valeurs peut améliorer les performances. La création de liens sur de grands projets peut prendre
grandes quantités de mémoire. Exécution d'éditeurs de liens parallèles, qui ne peuvent pas être exécutés à distance,
peut forcer la machine à permuter, ce qui réduit les performances par rapport à la simple exécution des tâches dans
séquence sans permutation. Obtenir le bon nombre de préprocesseurs parallèles
vous permet d'utiliser des facteurs parallèles plus importants avec make, puisque la machine locale a maintenant
mécanisme de mesure de l'utilisation des ressources locales.

Enfin, il y a l'entrée hôte

Les performances dépendent des détails de la source et des makefiles utilisés pour le projet, et
les vitesses de la machine et du réseau. Expérimenter avec différents paramètres pour la liste d'hôtes
ainsi que -j facteur peut améliorer les performances.

La syntaxe est

DISTCC_HOSTS = HOSTSPEC...
HOSTSPEC = LOCAL_HOST | SSH_HÔTE | TCP_HOST | OLDSTYLE_TCP_HOST
| GLOBAL_OPTION
| ZÉROCONF
LOCAL_HOST = hôte local[/LIMIT]
| --localslots=
| --localslots_cpp=
SSH_HOST = [USER]@HOSTID[/LIMIT][:COMMAND][OPTIONS]
TCP_HOST = HOSTID[:PORT][/LIMIT][OPTIONS]
OLDSTYLE_TCP_HOST = HOSTID[/LIMIT][:PORT][OPTIONS]
ID HÔTE = NOM HÔTE | IPV4 | IPV6
OPTIONS = ,OPTION[OPTIONS]
OPTION = lzo | RPC
GLOBAL_OPTION = --randomiser
ZEROCONF = +zéroconf

Voici quelques exemples individuels de la syntaxe :

localhost
Le mot littéral "localhost" est interprété spécialement pour provoquer des compilations
directement exécuté, plutôt que transmis à un démon sur la machine locale. Si tu fais
voulez vous connecter à un démon sur la machine locale pour le test, puis donnez le
l'adresse IP ou le nom d'hôte réel de la machine. (Ce sera plus lent.)

IPV6 Une adresse IPv6 littérale entre crochets, telle que [::1]

IPV4 Une adresse IPv4 littérale, telle que 10.0.0.1

HOSTNAME
Un nom d'hôte à rechercher à l'aide du résolveur.

:PORT Connectez-vous à un numéro de port décimal spécifié, plutôt que la valeur par défaut de 3632.

@IDHÔTE
Connectez-vous à l'hôte via SSH, plutôt que TCP. Les options pour la connexion SSH peuvent
être mis en ~ / .ssh / config

UTILISATEUR@ Connectez-vous à l'hôte via SSH en tant que nom d'utilisateur spécifié.

:COMMANDER
Connectez-vous via SSH et utilisez un chemin spécifié pour trouver le serveur distccd. C'est
normalement nécessaire uniquement si, pour une raison quelconque, vous ne pouvez pas installer distccd dans un répertoire
sur le PATH par défaut pour les connexions SSH. Utilisez ceci si vous obtenez des erreurs telles que "distccd :
commande introuvable" en mode SSH.

/LIMITE Une limite décimale peut être ajoutée à n'importe quelle spécification d'hôte pour restreindre le nombre de
travaux que ce client enverra à la machine. La limite est par défaut de quatre par
host (deux pour localhost), mais peut être davantage restreint par le serveur. Vous devriez
il suffit de l'augmenter pour les serveurs avec plus de deux processeurs.

,lzo Active la compression LZO pour cet hôte TCP ou SSH.

,cpp Active le mode distcc-pump pour cet hôte. Remarque : la commande build doit être encapsulée dans
le script distcc-pump afin de démarrer le serveur d'inclusion.

--randomiser
Randomiser l'ordre de la liste d'hôtes avant l'exécution.

+zéroconf
Ce option is uniquement disponibles if distcc était compilé avec Avahi Support activé at
configurer le temps. Lorsque cette entrée spéciale est présente dans la liste des hôtes, distcc
utilisez Avahi Zeroconf DNS Service Discovery (DNS-SD) pour localiser tout distccd disponible
serveurs sur le réseau local. Cela évite d'avoir à lister explicitement l'hôte
noms ou adresses IP des machines du serveur distcc. Les serveurs distccd doivent avoir
démarré avec l'option "--zeroconf" de distccd. Une mise en garde importante est que
dans l'implémentation actuelle, le mode pompe (",cpp") et la compression (",lzo") seront
ne jamais être utilisé pour les hôtes situés via zeroconf.

Voici un exemple démontrant quelques possibilités :

hôte local/2 @bigman/16:/opt/bin/distccd ancienne machine: 4200/1
# charretier is down
distant/3,lzo

Les commentaires sont autorisés dans les spécifications de l'hôte. Les commentaires commencent par un signe dièse/dièse (#)
et courir jusqu'au bout de la ligne.

Si un hôte de la liste n'est pas accessible, distcc émettra un avertissement et ignorera cet hôte pendant
environ une minute.

COMPRESSION

La lzo l'option hôte spécifie que la compression LZO doit être utilisée pour le transfert de données,
y compris la source prétraitée, le code objet et les messages d'erreur. La compression est généralement
économique sur les réseaux inférieurs à 100Mbps, mais les résultats peuvent varier selon le réseau,
processeurs et arborescence des sources.

L'activation de la compression fait que le client et le serveur distcc utilisent plus de temps CPU, mais moins
trafic réseau. Le temps CPU ajouté est insignifiant pour le mode pompe. La compression
le ratio est généralement de 4:1 pour la source et de 2:1 pour le code objet.

L'utilisation de la compression nécessite que le client et le serveur utilisent au moins la version 2.9 de distcc.
Aucune configuration de serveur n'est requise : le serveur répond toujours avec des réponses compressées à
requêtes compressées.

Le mode de pompage nécessite que les serveurs aient l'option hôte lzo activée.

Rechercher Les chemins

Si le nom du compilateur est un chemin absolu, il est transmis textuellement au serveur et le
le compilateur est exécuté à partir de ce répertoire. Par exemple:

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

Si le nom du compilateur n'est pas absolu ou n'est pas entièrement qualifié, le PATH de distccd est recherché.
Lorsque distcc est exécuté à partir d'un répertoire de mascarade, seul le nom de base du compilateur est
utilisé. Le PATH du client est utilisé uniquement pour exécuter le préprocesseur et n'a aucun effet sur le
chemin du serveur.

TEMPS MORT

Le client et le serveur distcc imposent des délais d'attente pour le transfert de données sur le réseau.
Ceci est destiné à détecter les hôtes qui sont en panne ou inaccessibles, et à empêcher les compilations
suspendu indéfiniment si un serveur est déconnecté en cours d'utilisation. Si un délai d'attente côté client
expire, la tâche sera réexécutée localement.

Les délais d'attente ne sont pas configurables pour le moment.

DIAGNOSTIC

Les messages d'erreur ou les avertissements des compilateurs locaux ou distants sont transmis au diagnostic
sortie sur le client.

distcc peut fournir des informations de débogage complètes lorsque l'option verbose est utilisée. Cette
est commandé par l' DISTCC_VERBOSE variable d'environnement sur le client, et la --verbeux
option sur le serveur. Pour le dépannage, examinez à la fois l'erreur client et serveur
des messages.

EXIT CODES

Le code de sortie de distcc est normalement celui du compilateur : zéro pour une compilation réussie
et non nul sinon.

distcc fait la distinction entre les erreurs "authentiques" telles qu'une erreur de syntaxe dans la source, et
des erreurs « accidentelles » telles qu'un problème de réseau de connexion à un volontaire. Dans le cas
d'erreurs accidentelles, distcc réessaiera la compilation localement à moins que le DISTCC_FALLBACK
l'option a été désactivée.

Si le compilateur se termine avec un signal, distcc renvoie un code de sortie de 128 plus le signal
.

les erreurs internes distcc provoquent un code de sortie compris entre 100 et 127. En particulier

100 Défaillance générale du disque.

101 Mauvais arguments.

102 Échec de la liaison.

103 Échec de la connexion.

104 Le compilateur a planté.

105 Mémoire insuffisante.

106 Mauvais hôte SPEC

Erreur d'E / S 107

108 Tronqué.

109 Erreur de protocole.

110 Le compilateur indiqué n'a pas été trouvé sur l'hôte distant. Vérifiez que $CC est défini
correctement et qu'il est installé dans un répertoire sur le chemin de recherche de
distccd.

111 Appel récursif à distcc.

112 Échec de la suppression des privilèges.

113 Accès réseau refusé.

114 Utilisé par un autre processus.

115 Pas de tel fichier.

116 Aucun hôte défini et les solutions de secours désactivées.

118 Délai d'attente.

Utilisez distcc en ligne à l'aide des services onworks.net