include_server - En ligne dans le Cloud

PROGRAMME:

Nom

include_server.py - approximation prudente des dépendances d'inclusion pour C/C++

SYNOPSIS

inclure_serveur --Port INCLUDE_SERVER_PORT [OPTIONS]

DESCRIPTION

include_server.py démarre un processus de serveur d'inclusion. Ce processus répond aux requêtes de
distcc(1) les clients sur les fichiers à inclure dans les compilations C/C++. Le include_server.py
La commande elle-même se termine dès que le serveur d'inclusion a été généré.

L'argument INCLUDE_SERVER_PORT est le nom d'un socket utilisé pour toutes les communications
entre les clients distcc et le serveur d'inclusion. Les pompe-distcc(1) le commandement est responsable
pour créer l'emplacement du socket, pour le transmettre à ce script et pour le transmettre à tous
clients distcc via la variable d'environnement nommée INCLUDE_SERVER_PORT.

Le protocole utilisé par le serveur d'inclusion utilise l'implémentation RPC de distcc. Chaque distcc
La requête se compose (1) du répertoire courant et (2) de la liste des arguments du
commande de compilation.

Si le serveur d'inclusion est capable de traiter la requête, il répond au client distcc en
envoyer une liste de chemins de fichiers. Les chemins de fichiers sont ceux de la source et de l'en-tête compressés
fichiers jugés nécessaires pour la compilation par analyse d'inclusion. La liste aussi
comprend des liens symboliques et même des fichiers factices nécessaires au serveur de compilation pour
construire une réplique précise des parties du système de fichiers nécessaires à la compilation. Dans
de cette façon, un fichier d'en-tête nécessaire comme /path/foo.h est compressé, renommé et stocké dans un
emplacement temporaire, tel que /dev/shm/tmpiAvfGv.include_server-9368-1/path/foo.h.lzo. Les
le client distcc transmettra ces fichiers à un serveur de compilation, où ils seront
décompressé et monté temporairement.

Si le serveur d'inclusion n'est pas en mesure de traiter la demande, il renvoie la liste vide
au client distcc.

Il existe deux types d'échecs liés au serveur d'inclusion. Le serveur d'inclusion peut
échouer à calculer les inclusions ou échouer d'une autre manière, voir la section COMPRENDRE SERVEUR SYMPTÔMES.
En outre, la compilation sur le serveur de suppression peut échouer en raison de l'insuffisance du calcul
inclure la fermeture, mais réussir ensuite lors d'une nouvelle tentative locale, voir la section DISTCC CONTRADICTION
SYMPTÔMES.

OPTION RÉSUMÉ

Les options suivantes sont comprises par include_server.py.

-dPAT, --debug_pattern=PAT
Vecteur de bits pour activer les avertissements et le débogage
1 = avertissements
2 = tracer des fonctions
autres puissances de deux : voir include_server/basics.py.

-e, --e-mail
Envoyer un e-mail à 'distcc-pump-errors' ou si défini, la valeur de la variable d'environnement
DISTCC_EMAILLOG_WHOM_TO_BLAME, lorsque le serveur d'inclusion rencontre des problèmes. La valeur par défaut est
de ne pas envoyer d'e-mail.

--email_bound NUMÉRO
Nombre maximum d'emails à envoyer (en plus d'un email final). Par défaut : 3.

--pas d'e-mail
N'envoyez pas d'e-mail. C'est la valeur par défaut.

--path_observation_re=RE
Émettre un message d'avertissement chaque fois qu'un nom de fichier est résolu en un chemin réel qui correspond
par RE, qui est une expression régulière en syntaxe Python. Ceci est utile pour trouver
d'où proviennent réellement les fichiers inclus. Utilisez RE="" pour les trouver tous. Noter:
les avertissements doivent être activés avec au moins -d1.

--pid_file CHEMIN DU FICHIER
Le pid du serveur d'inclusion est écrit dans le fichier FILEPATH. Cela permet à un script
tel pompe-distcc pour détruire le serveur d'inclusion.

-Oui, --statistiques
Imprimer les informations sur stdout à propos de l'analyse d'inclusion.

--stat_reset_triggers=LISTE
Videz les caches de statistiques lorsque l'horodatage d'un chemin de fichier dans la LISTE change ou que le
chemin de fichier entre ou n'existe plus. LISTE est une chaîne séparée par deux points de
chemins de fichiers, contenant éventuellement des globs simples (comme autorisé par le module glob de Python).
Imprimez un avertissement chaque fois qu'un tel changement se produit (si les avertissements sont activés). Cette
L'option permet des exceptions limitées à l'hypothèse normale de distcc-pump selon laquelle la source
les fichiers ne sont pas modifiés pendant la construction.

-t, --temps
Imprimez le temps écoulé, l'utilisateur et le système sur stderr.

--unsafe_absolute_includes
Faire un prétraitement sur le serveur de compilation même si inclut des chemins de fichiers absolus
sont rencontrés. Normalement, le serveur d'inclusion se rabattra sur le prétraitement local
s'il détecte des inclusions absolues. Ainsi, ce drapeau est utile pour empêcher de tels
les replis lorsque les inclusions absolues sont une fausse alarme, soit parce que l'absolu
include est ignoré pendant le prétraitement ou parce que le fichier absolument inclus
existe sur les serveurs de compilation.

Plus précisément, avec --unsafe_absolute_includes les inclusions absolues sont ignorées pour
les buts de la collecte de la fermeture de l'include. L'utilisation de cette option peut entraîner
résultats incorrects parce que (1) l'en-tête peut en fait être inclus sur le
serveur de compilation et ce n'est peut-être pas le même que sur le client, (2) l'include
les directives de l'en-tête ne sont pas analysées plus avant.

L'option est utile pour compiler du code qui a de tels emplacements absolus codés en dur
des fichiers d'en-tête à l'intérieur des directives conditionnelles (par exemple "#ifdef") qui rendent le
inclut non pertinent. Plus précisément, ces inclusions doivent être éliminées lors de
prétraitement pour la configuration réelle. Ensuite, la question de l'existence du
le fichier d'en-tête est sans objet et la compilation à distance est saine. C'est souvent le cas si
ces inclusions sont destinées à des configurations inhabituelles différentes de la réalité
configuration.

-dans, --Vérifier
Vérifier que les fichiers de la clôture CPP sont contenus dans la clôture calculée par include
processeur.

-w, --write_include_closure
Ecrivez un fichier .d_approx qui répertorie tous les fichiers inclus calculés par l'include
serveur; avec -x, écrivez en plus les fichiers inclus tels que calculés par CPP dans un
fichier .d_exact.

-X, --analyse_exacte
Utilisez plutôt CPP, n'omettez pas les fichiers d'en-têtes système.

COMPRENDRE SERVEUR SYMPTÔMES ET QUESTIONS

Les messages et avertissements les plus susceptibles de provenir du processeur d'inclusion sont répertoriés ci-dessous.

Prétraitement localement. Comprendre serveur ne sauraient couvrant: ne pouvait pas déterminer défaut combustion propre
comprendre répertoires
Pour déterminer les répertoires d'en-tête du système par défaut, le serveur d'inclusion exécute le
compilateur une fois pour chaque langue nécessaire au cours de sa session. Ce message indique
que le compilateur spécifié à distcc n'est pas présent sur le client.

Prétraitement localement. Comprendre serveur ne sauraient couvrant: Renflouer ande car comprendre serveur
dépensé PLUS que ...s utilisateur fiable manipulation nécessaire
Dans des situations rares, le serveur d'inclusion ne parvient pas à analyser une macro très compliquée
expressions. Le client distcc utilisera le mode distcc simple.

Mise en garde: Chemin du fichier must be relatif mais n'est pas
Le serveur d'inclusion n'accepte pas les chemins de fichiers absolus, tels que
/usr/include/stdio.h, dans les directives include, car il n'y a aucune garantie que
cet en-tête sur la machine du serveur de compilation sera le même que celui sur le
client. Le serveur d'inclusion abandonne l'analyse de la fermeture d'inclusion. Le distcc
le client ne peut pas utiliser le mode pompe.

Pour surmonter ce problème de manière pas toujours fiable, définissez la variable d'environnement
INCLUDE_SERVER_ARGS='--unsafe_absolute_includes' lors de l'appel de la pompe distcc
script pour transmettre l'option --unsafe_absolute_includes au serveur d'inclusion.

Mise en garde: Absolute chemin du fichier était IGNORÉ
Le --unsafe_absolute_includes est en cours d'utilisation. Cette situation se produit sous le même
circonstances comme lorsque "Le chemin du fichier doit être relatif mais ne l'est pas" est émis, mais dans ce
cas, l'include fournira une réponse au client distcc.

Mise en garde: Chemin '/CHEMIN/FICHIER' changé/est venu développement existence/non plus long existe
Ces avertissements sont émis lors de l'utilisation des déclencheurs de réinitialisation des statistiques. Parce que /CHEMIN/FICHIER
modifié, le serveur d'inclusion efface ses caches ; la nouvelle version du fichier (ou le
l'absence de celui-ci) rend l'analyse d'inclusion invalide. Ce message peut généralement être
ignoré; cela signifie une utilisation quelque peu précaire des fichiers par le système de construction.
Il est recommandé de corriger le système de compilation afin que les fichiers ne soient pas réécrits.

Mise en garde: Pour traductions unité ..., rechercher of filet résolu à dont chemin réel is

Cet avertissement se produit avec --path_observation_re lorsqu'un nouveau chemin réel correspondant à un
le fichier source ou d'en-tête est observé.

DISTCC CONTRADICTION SYMPTÔMES

Les interactions entre le système de construction, distcc et le serveur d'inclusion sont quelque peu
complexe. Lorsqu'une commande distcc reçoit une compilation défaillante du serveur distant, elle
retente la compilation localement. Cette section traite des causes des écarts
entre la compilation distante et locale. Ceux-ci sont signalés par le message de rétrogradation :

__________Avertissement: mode pompe compilation(s) manqué on serveur, mais réussi localement.
__________Distcc-pompe était rétrogradé à plaine mode. See le Distcc Contradiction Symptômes
in le inclure_serveur(1) man .

Le script distcc-pump émet ce message à la fin de la construction. Cela signifie que pour au
au moins une invocation distcc une compilation locale a réussi après la compilation à distance
échoué. Chaque invocation distcc pour laquelle un tel écart s'est produit à son tour émet également un
message tel que :

Mise en garde: éloigné compilation of '...' échoué, réessayé localement ainsi que eu a différent résultat.

La rétrogradation oblige les invocations distcc suivantes à utiliser le mode distcc simple. Ainsi
le prétraitement aura lieu sur la machine locale pour le reste de la construction. Cette
La technique empêche les builds très lents où toutes les compilations se retrouvent sur la machine locale
après avoir échoué à distance.

Bien sûr, si les compilations locales échouent après les échecs distants, alors le distcc
l'invocation se termine avec le statut non nul de la compilation locale. Les messages d'erreur
imprimés sont aussi ceux de la compilation locale.

Le comportement de repli du mode distcc-pump vers la compilation locale peut être désactivé en définissant
la variable d'environnement DISTCC_FALLBACK à 1, ce qui fait échouer la commande distcc dès
car la compilation à distance a échoué. Ce paramètre est très utile pour déboguer pourquoi le
la compilation à distance s'est mal passée, car maintenant la sortie du serveur sera imprimée.

Ensuite, nous discutons des causes possibles des écarts.

La utilisateur modifié a la source or entête filet pendant le construire.
Cela donne bien sûr des résultats incohérents.

A la source or entête filet modifié pendant le construire.
Le système de génération réécrit un fichier. Pour le noyau Linux 2.6, cela se produit pour
'include/linux/compile.h' et 'include/asm/asm-offsets.h'. Cette condition est fixée
en informant le serveur d'inclusion qu'il doit réinitialiser ses caches lorsqu'une statistique de n'importe quel
des changements de fichiers. Pratiquement, cela se fait en rassemblant les fichiers dans un colon-
liste séparée, puis en définissant la commande INCLUDE_SERVER_ARGS comme dans :

include_server_args="--stat_reset_triggers=include/linux/compile.h:include/asm/asm-
décalages.h"

A entête filet is l'éventualité inclus, mais ne sauraient exister, ainsi que is puis plus tard inclus.

Cela se produit lorsqu'un en-tête foo.h inclut un autre fichier d'en-tête trick.h, mais le
Le fichier trick.h n'a pas encore été généré et l'inclusion est en fait ignorée
à cause des directives de prétraitement. Le serveur d'inclusion recherchera le
existence de trick.h, car il surapproche toutes les directives de manières possibles
évaluer réellement. Le fichier trick.h est déterminé à ne pas exister. Si c'est plus tard
généré, puis réellement inclus, le serveur d'inclusion croira à tort
que le fichier n'existe toujours pas. La solution à ce problème est de faire
le système de construction génère trick.h avant la première fois qu'un fichier d'en-tête est inclus
qui fait une référence syntaxique à trick.h

La comprendre serveur était j'ai commencé avec --unsafe_absolute_includes.
C'est un problème s'il y a des fichiers d'en-tête localement qui n'existent pas à distance et
qui sont réellement utilisés. Ces inclusions sont souvent protégées par des conditions
directives qui évaluent de sorte qu'elles ne soient effectivement utilisées que sur des sujets spécifiques et souvent
plates-formes peu communes. Si vous ne compilez pas pour une telle plate-forme, il peut être
correct à utiliser --unsafe_absolute_include.

La comprendre serveur a calculé le mal comprend.
Nous ne connaissons pas une telle situation.

EXIT CODES

Le code de sortie de include_server.py est généralement 0. Que le serveur d'inclusion a été démarré
correctement est communiqué par l'existence du pid_file.

ENVIRONNEMENT VARIABLES

DISTCC_EMAILLOG_WHOM_TO_BLAME L'adresse e-mail à utiliser pour inclure le serveur automatisé
e-mails. La valeur par défaut est 'distcc-pump-errors' (qui est une adresse e-mail qui sera probablement
n'existe pas dans votre domaine).

De plus, l'appel du compilateur peut utiliser des variables d'environnement supplémentaires.

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