makepp_sandboxes - En ligne dans le Cloud

PROGRAMME:

Nom

makepp_sandboxes -- Comment partitionner une compilation makepp

DESCRIPTION

D: --faire-construire,
--ne pas construire,
--ne pas lire,
--faire-lire, I: --dans-bac à sable,
--intérieur-bac à sable, O: --hors bac à sable, S: --bac à sable,
--sandbox-warn,
--avertissement-bac à sable, V: --bac à sable virtuel

Il y a plusieurs raisons pour lesquelles vous voudrez peut-être partitionner l'arborescence des fichiers pour un makepp
construire:

1. Si vous savez que la majorité de l'arbre n'est pas affectée par les modifications apportées à
sources depuis la version précédente, alors vous pouvez dire à makepp de supposer que les fichiers
dans ces parties de l'arbre sont déjà à jour, ce qui signifie même pas implicitement
charger leurs makefiles, sans parler du calcul et de la vérification de leurs dépendances. (Noter
que les makefiles explicitement chargés sont toujours chargés, cependant.)

2. Si vous avez plusieurs processus makepp accédant au même arbre, alors vous voulez augmenter
une erreur si vous détectez que deux processus concurrents écrivent la même partie du
arbre, ou qu'un processus lit une partie de l'arbre qu'un processus concurrent est
l'écriture. Dans tous les cas, vous avez une condition de concurrence dans laquelle l'ordre relatif des événements
dans deux processus concurrents (ce qui ne peut être garanti) peut affecter le résultat.

Makepp dispose d'installations de sandboxing qui répondent à ces deux problèmes.

Sandboxing Options
Les options makepp suivantes peuvent être utilisées pour définir les propriétés de sandbox du sous-arbre
donné par chemin et tous ses fichiers et fichiers potentiels :

--ne pas construire chemin
--do-build chemin
Définissez ou réinitialisez la propriété "dont-build". Tout fichier avec ce jeu de propriétés est supposé
être déjà à jour et aucune vérification de build ne sera effectuée. La valeur par défaut est réinitialisée
(ie "do-build"), sauf si vous avez un "RootMakeppfile", auquel cas tout
en dehors de son ID de sous-arbre "dont-build".

--bac à sable chemin
--dans-bac à sable chemin
--intérieur-bac à sable chemin
--hors bac à sable chemin
Définissez ou réinitialisez la propriété "in-sandbox". Une erreur est générée si makepp le ferait autrement
écrivez un fichier avec cette propriété réinitialisée. Les contrôles de build sont toujours effectués, à moins que le
La propriété "dont-build" est également définie. La valeur par défaut est définie (c'est-à-dire "dans le bac à sable"), à moins que
il y en a --bac à sable options, auquel cas la valeur par défaut pour tous les autres fichiers est
reset (c'est-à-dire "hors bac à sable").

--sandbox-avertir
--sandbox-avertissement
Rétrogradez les violations de « in-sandbox » et « dont-read » en avertissements au lieu d'erreurs.
Ceci est utile lorsqu'il y a des centaines de violations, afin que vous puissiez collecter toutes les
en une seule fois et prendre les mesures correctives appropriées. Sinon, vous ne voyez que
une violation par invocation makepp, et vous ne savez pas combien il en reste avant
ils sont tous réparés.

--ne pas lire chemin
--faire-lire chemin
Définissez ou réinitialisez la propriété « dont-read ». Une erreur est générée si makepp le ferait autrement
lire un fichier avec ce jeu de propriétés. La valeur par défaut est réinitialisée (c'est-à-dire "do-read").

--bac à sable virtuel
Ne réécrivez pas les informations de build des fichiers qui n'ont pas été créés par ce processus makepp. Cette
est utile lors de l'exécution de processus makepp simultanés avec des bacs à sable qui se chevauchent, et vous
sont certains que deux processus ne tenteront pas de construire la même cible. Makepp va
puis s'abstenir de mettre en cache des informations supplémentaires sur les fichiers qu'il lit, car
il pourrait y avoir d'autres lecteurs simultanés.

Chacune de ces 3 propriétés s'applique à l'ensemble de la sous-arborescence, y compris aux fichiers qui ne
existent encore. Les chemins plus spécifiques remplacent les chemins moins spécifiques. Un chemin spécifié peut être un
fichier individuel, même si le fichier n'existe pas encore.

Si une propriété est à la fois définie et réinitialisée sur exactement le même chemin, l'option qui apparaît
le plus à droite sur la ligne de commande est prioritaire.

Sandboxing en ACCÉLÉRATION
Si vous voulez empêcher makepp de perdre du temps à traiter des fichiers que vous savez déjà
à jour (en particulier les fichiers générés par un outil de build autre que makepp),
puis --ne pas construire est l'option pour vous.

Le cas de loin le plus courant pour une telle optimisation est que vous savez que tout ce qui n'est pas
au niveau ou en dessous du répertoire de départ est déjà à jour. Cela peut être communiqué à
makepp en utilisant "--ne pas construire /. --do-build .".

Sandboxing en Concurrent Le processus
Une technique qui peut réduire la latence de construction consiste à faire fonctionner plusieurs processus makepp
sur le même arbre. C'est un peu plus difficile à gérer que d'utiliser le -j option,
mais il peut aussi être considérablement plus efficace car :

· Avec le sandboxing, les processus peuvent s'exécuter sur plusieurs hôtes, par exemple via une tâche
système de file d'attente. Augmenter le -j limit finit par épuiser les ressources CPU d'un
hôte unique, et peut même ralentir la construction en raison d'un fork excessif de processus.

· -j ne parallélise actuellement pas certaines des tâches fastidieuses de makepp telles que le chargement
makefiles, analyse, création de dépendances implicites lors de l'analyse et vérification
dépendances.

Le plus grand risque avec cette approche est que la construction peut devenir non déterministe si
les processus qui pourraient être concurrents interagissent les uns avec les autres. Cela conduit à construire des systèmes
qui produisent des résultats incorrects sporadiquement, et sans mécanisme simple pour déterminer pourquoi
ça arrive.

Pour faire face à ce risque, il est conseillé de partitionner l'arborescence entre des processus concurrents
de telle sorte que si un processus accède au système de fichiers de manière incorrecte, une erreur est
levé immédiatement de manière déterministe. Normalement, cela est accompli en affectant à chaque
processus concurrent un "bac à sable" dans lequel il est permis d'écrire, où les bacs à sable de aucun
deux processus concurrents peuvent se chevaucher.

De plus, chaque processus marque les bacs à sable de tout autre processus éventuellement concurrent
comme "ne pas lire". Si un processus lit un fichier dont un autre processus concurrent est responsable
pour l'écriture (et qui pourrait donc ne pas encore être écrite), alors une erreur est levée
immédiatement.

Sandboxing en Séquentiel Le processus
Lorsque la construction est partitionnée pour les processus makepp simultanés, il y a aussi généralement un
relation séquentielle entre diverses paires de processus. Par exemple, il peut y avoir un
une douzaine de processus de compilation simultanés, suivis d'un processus de liaison unique qui ne peut pas commencer
jusqu'à ce que tous les processus de compilation soient terminés. De telles relations séquentielles doivent être
appliqué par tout mécanisme qui orchestre les divers processus makepp (par exemple,
le système de file d'attente des travaux).

Lorsque les processus ont une relation séquentielle connue, il n'est normalement pas nécessaire de lever une
erreur lorsqu'ils accèdent à la même partie de l'arbre, car le résultat est néanmoins
déterministe.

Cependant, il est généralement avantageux de préciser --ne pas construire options à la personne à charge
processus (le processus de liaison dans notre exemple) qui lui notifie les zones qui ont déjà
été mis à jour par les processus prérequis (les tâches de compilation dans notre exemple). Dans ce
manière, nous évitons la plupart du travail inutile de création d'objectifs nuls qui étaient juste
mise à jour.

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