makepp_build_cache_control - En ligne dans le Cloud

PROGRAMME:

Nom

makepp_build_cache -- Comment configurer et utiliser les caches de construction

DESCRIPTION

C: nettoyer,
créer, M: makepp_build_cache_control,
mppbcc, S: montrer,
stats

A construire cachette est un répertoire contenant des copies des cibles précédentes que makepp a déjà
construit. Quand makepp est invité à construire une nouvelle cible, il voit s'il l'a déjà construit
ailleurs dans les mêmes conditions, et si c'est le cas, il suffit de le lier ou de le copier au lieu de
le reconstruire.

Un cache de build peut être utile dans les circonstances suivantes :

· Vous travaillez sur un programme et vous le compilez optimisé. Ensuite, vous découvrez un bug,
et recompiler le tout en mode débogage. Vous trouvez le bug et vous voulez maintenant
le recompiler en mode optimisé. La plupart des fichiers seront identiques. Si vous avez utilisé un
build cache dans toutes vos compilations, makepp va simplement extraire les fichiers inchangés
du cache de construction plutôt que de les recompiler.

Une situation similaire est si vous travaillez normalement sur une architecture mais passez brièvement à
une architecture différente, puis vous revenez en arrière. Si les anciens fichiers sont toujours dans le
cache de construction, makepp n'aura rien à recompiler.

· Vous avez extrait plusieurs copies d'un programme particulier à partir de votre contrôle de version
système et ont apporté des modifications différentes à chaque hiérarchie de répertoires. (Par exemple, vous êtes
résoudre différents bogues dans différentes hiérarchies de répertoires.) La plupart des fichiers seront
identiques dans les deux hiérarchies de répertoires. Si vous construisez les deux avec un cache de construction, le
build dans la deuxième hiérarchie de répertoires pourra simplement copier les fichiers du
construire le cache plutôt que de recompiler des fichiers identiques.

· Vous avez plusieurs développeurs travaillant sur le même ensemble de sources. Chaque développeur est
apporter des modifications, mais la plupart des fichiers sont identiques entre les développeurs. Si tous les
les développeurs partagent un cache de build, alors si la build d'un développeur compile un fichier, tout
build d'un autre développeur qui doit compiler le même fichier (avec le même
inclut, etc.) peut simplement copier le fichier mis en cache au lieu de réexécuter la compilation.

Un cache de build peut aider si toutes les conditions suivantes sont vraies :

· Vous disposez de beaucoup d'espace disque. Habituellement, makepp finira par mettre en cache de nombreuses copies de
chaque fichier qui change, car il n'a aucune idée de ceux qui seront réellement utilisés.
Vous pouvez désactiver le cache de build pour certains fichiers, mais si le cache de build va
être utile, il devra probablement contenir beaucoup de fichiers.

· Vos fichiers prennent sensiblement plus de temps à créer qu'à copier. Si le cache de construction est sur le
même système de fichiers, makepp essaiera d'utiliser des liens physiques plutôt que de copier le fichier.
Makepp doit lier ou copier le fichier dans le cache lorsque le fichier est construit, puis il
doit lier ou copier le fichier à partir du cache lorsqu'il est à nouveau requis. Par ailleurs,
il y a une petite surcharge impliquée dans la vérification si le fichier nécessaire est réellement dans
le cache de construction et en copiant les informations de construction sur le fichier ainsi que le fichier
elle-même.

Vous constaterez peut-être, par exemple, que l'utilisation d'un cache de construction ne vaut pas la peine pour une compilation très
petits modules. Cela ne vaut presque certainement pas la peine que les commandes fassent un statique
bibliothèque (un fichier d'archive, libxyz.a), sauf si vous utilisez des liens pour économiser de l'espace disque.

· Il y a une forte probabilité que certains fichiers soient à nouveau nécessaires dans un autre
compilation. Si vous ne compilez qu'une seule fois un logiciel, les caches de construction peuvent
seulement ralentir les choses.

L'utilisation d'un cache de construction nécessite un peu de travail de configuration et de maintenance. Merci de ne pas
essayez d'utiliser un cache de construction jusqu'à ce que vous compreniez comment ils fonctionnent, comment les créer et comment
les empêcher de croître continuellement et de consommer tout l'espace disque disponible sur votre
système.

Comment a construire cachette vos contrats
Si vous activez un cache de construction, chaque fois qu'un fichier est construit, makepp stocke une copie dans un
cache de construction. Le nom du fichier est une clé qui est un hachage des sommes de contrôle de tous les
entrées et la commande build et l'architecture. La prochaine fois que makepp veut reconstruire
le fichier, il voit s'il existe un fichier avec les mêmes sommes de contrôle déjà dans le cache de construction.
Si tel est le cas, le fichier est copié hors du cache de génération.

Pour plus d'efficacité, si le cache de build est situé sur le même système de fichiers que le build, makepp
ne copiera pas réellement le fichier ; au lieu de cela, il fera un lien dur. C'est plus rapide et
n'utilise pas d'espace disque supplémentaire. De même, lorsque makepp veut extraire un fichier de
le cache de construction, il utilisera un lien physique si possible, ou le copiera si nécessaire.

AVERTISSEMENT: Makepp jamais supprime les fichiers d'un cache de construction à moins que cela ne soit explicitement demandé.
Cela signifie que vos caches de build continueront de croître sans limites à moins que vous ne nettoyiez
régulièrement (voir ci-dessous pour plus de détails).

Silhouette caches et code source

Construire des caches et des référentiels (voir makepp_repositories) peut résoudre des problèmes similaires. Pour
certaines situations, un référentiel est plus approprié, tandis que pour d'autres, un cache de construction est plus
approprié.

Vous pouvez également combiner les deux. Si vous avez une énorme structure de répertoires avec beaucoup de
sources, dont vous ne voulez pas que chaque développeur ait une copie, alors vous pouvez les fournir
en tant que référentiel. Les fichiers produits, avec diverses options de débogage et ainsi de suite, peuvent ensuite être
géré de manière plus flexible via un cache de construction.

Les principales différences entre un cache de build et un référentiel sont :

· Un cache de construction ne peut stocker que les fichiers créés par la procédure de construction. Un référentiel peut
ont également des fichiers sources originaux.

· Les fichiers dans un référentiel doivent pas changer au cours d'une construction. Un cache de construction
n'a pas une telle restriction.

· Les fichiers dans un référentiel doivent être présents dans la même position relative que les fichiers dans
le répertoire de construction. Par exemple, si makepp a besoin du fichier sous-rép1/sous-rép2/xyz.abc, puis il
ne regarde que racine_référentiel/sous-rép1/sous-rép2/xyz.abc. Les fichiers dans un cache de build ont
perdu toutes les informations sur la hiérarchie des répertoires et ne sont recherchés que sur la base des entrées
et la commande qui ont été nécessaires pour les produire.

· Les fichiers d'un référentiel sont liés de manière logicielle à leurs nouveaux emplacements dans la construction
répertoires. Les fichiers d'un cache de build sont soit copiés, soit liés en dur dans leur nouveau
Emplacements. Si une copie est nécessaire, un référentiel sera certainement plus rapide.

· Les caches de construction coûtent un peu de temps pour y placer des fichiers. Un référentiel n'a pas
tout surcoût (pour l'exécution en cours, c'est-à-dire qu'il y avait bien sûr le coût de création
cela à l'avance), mais nécessite souvent une planification un peu plus avancée.

En général, un référentiel est plus utile si vous avez une seule version centrale que vous souhaitez
tous les développeurs de prendre des fichiers. Un cache de construction est ce que vous voulez si vous avez un
système décentralisé où un développeur doit emprunter des fichiers compilés à un autre
développeur.

Les caches de build et les référentiels peuvent aider avec les builds de variantes. Par exemple, si vous voulez
pour compiler toutes vos sources optimisées, puis à nouveau avec débogage, puis à nouveau optimisées,
vous pouvez éviter de recompiler à nouveau tous les fichiers optimisés en utilisant soit un référentiel, soit un
cache de construction. Pour ce faire avec un référentiel, vous devez penser à l'avance et dire explicitement
makepp pour utiliser un référentiel pour la compilation de débogage, sinon il effacera votre
compilation initiale optimisée. Avec un cache de construction, makepp va de l'avant et efface le
compilation initiale optimisée mais peut la récupérer rapidement.

Silhouette cachette regroupement
Un groupe est un couplage lâche de caches de construction. C'est lâche dans le sens où makepp ne
le gérer, afin de ne pas ralentir sa gestion du cache de build. Pour en profiter vous
devez utiliser l'utilitaire hors ligne. Notamment, la commande "clean" effectue également le
réplication. Si vous donnez un critère de nettoyage irréaliste, comme "--mtime=+1000", non
le nettoyage se produit, seule la réplication.

Le regroupement permet de partager des fichiers avec plus de personnes, surtout si vous avez vos caches de build
sur les disques des développeurs, pour bénéficier d'un hard linking, qui économise du temps de soumission et
espace disque. La liaison matérielle seule, cependant, est limitée aux avantages par disque.

Avec le regroupement, le fichier sera répliqué à un moment donné après que makepp l'a soumis au
cache de construction. Cela signifie que le fichier ne sera créé qu'une seule fois pour tous les disques ensemble.

Sur les systèmes de fichiers qui autorisent les liens physiques vers des liens symboliques -- ce qui semble limité à
Linux et Solaris -- le fichier sera en outre physiquement présent sur un seul disque.
De plus, il reste sur chaque disque sur lequel il a été créé avant la réplication, mais uniquement en tant que
tant qu'il est utilisé sur ces disques. Dans ce scénario avec des liens symboliques, vous pouvez choisir un ou
plusieurs systèmes de fichiers sur lesquels vous préférez que vos fichiers soient physiquement. Soit conscient que
les fichiers créés avec succès peuvent devenir indisponibles, si le disque sur lequel ils se trouvent disparaît physiquement
hors ligne. La reconstruction y remédiera, et l'impact peut être atténué en étendant le
fichiers sur plusieurs disques préférés.

La réplication a plusieurs utilisations intéressantes :

NFS (possible avec copie aussi)
Vous disposez d'un serveur NFS central qui fournit le cache de construction préféré. Chaque machine
et le disque du développeur a un cache de construction local pour une soumission rapide. Soit tu remontes
tous les disques de développeur sur le serveur NFS, et effectuez la réplication et le nettoyage
de manière centralisée, ou vous répliquez localement sur chaque machine cliente NFS, en ne traitant que la partie
du groupe qui y est visible.

Disque non sécurisé (possible avec copie aussi)
Si vous compilez sur un disque RAM (en éditant, espérons-le, vos sources dans un référentiel sur un
disque), vous pouvez faire en sorte que les disques sécurisés soient les préférés. Ensuite, la réplication
migrez les fichiers vers les disques sûrs, où ils survivent à un redémarrage. Après chaque redémarrage
vous devrez recréer le cache de construction du disque RAM et l'ajouter au groupe (ce qui
donner un avertissement, inoffensif dans ce cas, car les autres membres du groupe se souviennent encore
il).

Disque plein (lien dur vers des liens symboliques uniquement)
Si l'un de vos disques est notoirement plein, vous pouvez créer des caches de construction sur tous les
d'autres disques sont préférés. De cette façon, la réplication migrera les fichiers loin du
disque plein, de manière aléatoire à l'un des autres.

Comment à utilisé a construire cachette
Comment à dire makepp à utilisé le construire cachette

Une fois le cache de build créé, il est désormais disponible pour makepp. Il y a plusieurs
options que vous pouvez spécifier lors de la création ; voir "Comment gérer un cache de build" pour plus de détails.

Un cache de construction est spécifié avec l'option de ligne de commande --build-cache, avec le
instruction build_cache dans un makefile, ou avec le modificateur de règle :build_cache.

Les moyens les plus utiles que j'ai trouvés jusqu'à présent pour travailler avec les caches de construction sont :

· Définissez le chemin du cache de construction dans la variable d'environnement MAKEPPFLAGS, comme ceci (d'abord
variante pour Korn Shell ou bash, deuxième pour csh):

export MAKEPPFLAGS=--build-cache=/chemin/vers/build/cache
setenv MAKEPPFLAGS --build-cache=/chemin/vers/build/cache

Maintenant, chaque build que vous exécutez utilisera toujours ce cache de build, et vous n'avez pas besoin de
modifier quoi que ce soit d'autre.

· Spécifiez le cache de construction dans vos makefiles avec une ligne comme celle-ci :

BUILD_CACHE := /chemin/vers/build_cache
build_cache $(BUILD_CACHE)

Vous devez le mettre dans tous les makefiles qui utilisent un cache de construction (ou dans un include commun
fichier que tous les makefiles utilisent). Ou mettez ceci dans votre Fichier RootMakepp:

BUILD_CACHE := /chemin/vers/build_cache
build_cache global $(BUILD_CACHE)

Sur une machine multi-utilisateurs, vous pouvez configurer un cache de génération par disque domestique pour prendre
avantage des liens. Vous trouverez peut-être plus pratique d'utiliser une déclaration comme celle-ci :

build_cache $(find_upwards our_build_cache)

qui recherche vers le haut à partir du répertoire courant dans le système de fichiers courant jusqu'à ce qu'il
trouve un répertoire appelé notre_build_cache. Cela peut être la même déclaration pour tous
utilisateurs et pointent toujours individuellement vers le cache sur leur disque.

Solaris 10 peut effectuer un remontage sophistiqué des répertoires personnels. Votre maison sera
apparemment être un point de montage à part entière, appelé /maison/$NOMLOGICIEL, alors qu'en fait il est allumé
l'un des /exporter/accueil* disques aux côtés de ceux des autres utilisateurs. Parce que ce n'est pas
vraiment un système de fichiers séparé, les liens fonctionnent toujours. Mais vous ne pouvez pas chercher vers le haut.
Au lieu de cela, vous pouvez faire :

BUILD_CACHE := ${makeperl }

Silhouette caches et signatures

Makepp recherche les fichiers dans le cache de construction en fonction de leurs signatures. Si vous utilisez
la méthode de signature par défaut (date du fichier + taille), makepp ne retirera que les fichiers du
cache de construction si la date de fichier des fichiers d'entrée est identique. Selon la façon dont votre construction
fonctionne, les dates des fichiers peuvent ne jamais être identiques. Par exemple, si vous extrayez des fichiers dans
deux hiérarchies de répertoires différentes, les dates des fichiers correspondent probablement à l'heure à laquelle vous avez vérifié
les fichiers sortis, pas l'heure à laquelle les fichiers ont été archivés (en fonction, bien sûr, de votre
logiciel de contrôle de version).

Ce que vous voulez probablement, c'est extraire les fichiers du cache de construction si le fichier contenu are
identique, quelle que soit la date. Si tel est le cas, vous devriez utiliser une sorte de
une signature basée sur le contenu. Makepp le fait par défaut pour les compilations C et C++, mais il
utilise les dates de fichier pour tout autre type de fichier (par exemple, les fichiers objet ou tout autre fichier dans
le processus de construction n'est pas spécifiquement reconnu comme une source C ou un fichier d'inclusion). Si tu veux
d'autres types de fichiers pour travailler avec le cache de construction (c'est-à-dire, si vous voulez qu'il fonctionne avec
autre chose que des commandes de compilation C/C++), alors vous pouvez mettre une déclaration comme celle-ci
quelque part vers le haut de votre makefile :

signé md5

pour forcer makepp à utiliser des signatures basées sur le contenu des fichiers plutôt que sur leur date.

Comment pas à cachette certaines fichiers

Il peut y avoir certains fichiers que vous savez que vous ne voudrez jamais mettre en cache. Par exemple, si
vous insérez un horodatage dans un fichier, vous savez que vous ne le ferez en aucun cas
voulez récupérer une copie précédente du fichier hors du cache de construction, car l'horodatage
est différent. Dans ce cas, c'est juste une perte de temps et d'espace disque pour le copier dans le
cache de construction.

Ou, vous pouvez penser qu'il est hautement improbable que vous souhaitiez mettre en cache l'exécutable final.
Vous souhaiterez peut-être mettre en cache des objets individuels ou des objets partagés qui entrent dans la création du
exécutable, mais il est souvent assez improbable que vous construisiez un exactement identique
exécutable à partir d'entrées identiques. Encore une fois, dans ce cas, l'utilisation d'un cache de construction est un gaspillage de
l'espace disque et le temps, il est donc logique de le désactiver.

Parfois, un fichier peut être extrêmement rapide à générer, et c'est juste un gaspillage de le mettre dans
le cache de construction car il peut être généré aussi rapidement que copié. Vous voudrez peut-être
désactiver sélectivement la mise en cache de ces fichiers.

Vous pouvez désactiver le cache de construction pour des règles spécifiques en spécifiant " : build_cache none" dans
une règle, comme celle-ci :

our_executable : dateStamp.o main.o */*.so
: build_cache aucun
$(CC) $(LDFLAGS) $(entrées) -o $(sortie)

Ce drapeau signifie que les sorties de cette règle particulière ne seront jamais mises dans le
cache de construction, et makepp n'essaiera jamais non plus de les retirer du cache de construction.

Comment à gérer a construire cachette
makepp_build_cache_control commander
mppbcc commander

makepp_build_cache_control, mppbcc est un utilitaire qui administre les caches de construction pour makepp.
Ce que makepp_build_cache_control do est déterminé par le premier mot de son argument.

En fait, ce petit script est un wrapper pour la commande suivante, que vous voudrez peut-être
appelez directement dans vos tâches cron, où le chemin vers "makeppbuiltin" peut être nécessaire :

makeppbuiltin -MMpp::Commande BuildCacheControl ...

Vous pouvez également utiliser ces commandes à partir d'un makefile après les avoir chargées, avec un préfixe "&" comme
suit pour l'exemple de "créer":

perl { use Mpp::BuildCacheControl } # C'est un module Perl, donc utilisez au lieu d'inclure.

ma_cache :
&create $(CACHE_OPTIONS) $(output) # Appelle une fonction intégrée chargée.

build_cache $(pré-construire my_cache)

Les commandes valides, qui prennent également quelques-unes des options standard décrites dans
makepp_builtins, sont :

engendrent [option ...] chemin/vers/cache
Crée les caches de construction avec les options données. Les options valides sont :

Options standard : "-A, --args-file, --arguments-file=nom de fichier, -v, --verbose"

-e groupe
--étendre=groupe
--extend-groupe=groupe
Ajoutez le nouveau cache de build au "groupe". Cela peut avoir été un seul stand seul
construire le cache jusqu'à présent.

-f
--Obliger
Cela permet de créer le cache même si chemin/vers/cache existait déjà. Si c'était
un fichier, il est supprimé. Si c'était un répertoire, il est réutilisé, avec n'importe quoi
contenu qu'il avait.

-p
--préféré
Cette option n'a de sens que si vous avez des caches de build dans le groupe, qui permettent
lien dur vers des liens symboliques. Dans ce cas, le nettoyage migrera les membres vers le
disque préféré. Vous pouvez créer plusieurs caches au sein d'un groupe avec cette option, en
auquel cas les fichiers seront migrés de manière aléatoire vers eux.

-s n1,n2,...
--subdir-chars=n1,n2,...
Contrôle le nombre de niveaux de sous-répertoires créés pour contenir les fichiers mis en cache,
et combien de fichiers seront dans chaque sous-répertoire. La première n1 personnages de la
filename forment le nom du répertoire de niveau supérieur, et les caractères de n1 à n2 formulaire
le nom du répertoire de deuxième niveau, et ainsi de suite.

Les fichiers dans le cache de construction sont nommés à l'aide des hachages MD5 de données que makepp utilise, donc
chaque nom de fichier est composé de 22 chiffres en base64 plus le nom de fichier d'origine. Si un cache de construction
le nom du fichier est 0123456789abcdef012345_module.o, il est en fait stocké dans le build
cache comme 01/23/456789abcdef012345_module.o si vous spécifiez "--subdir-chars 2,4".
En fait, "--subdir-chars 2,4" est la valeur par défaut, qui est pour un gigantesque cache de construction
d'un maximum de 4096 répertoires avec 416777216 sous-répertoires. Même "--subdir-chars 1,2" ou
"--subdir-chars 1" vous mènera assez loin. Sur un système de fichiers optimisé pour d'énormes
répertoires, vous pouvez même dire "-s ''" ou "--subdir-chars=" pour stocker tous les fichiers dans
le niveau supérieur.

-m permanentes
--mode=permanentes
--access-permissions=permanentes
Spécifie les autorisations d'accès au répertoire lorsque des fichiers sont ajoutés à la construction
cache. Si vous voulez que d'autres personnes mettent des fichiers dans votre cache de build, vous devez faire
il groupe ou monde inscriptible. Les autorisations doivent être spécifiées en notation octale.

Comme il s'agit d'autorisations de répertoire, si vous accordez un accès, vous devez également accorder
exécuter l'accès, ou vous obtiendrez un tas d'échecs étranges. C'est-à-dire 0700 signifie que
seul cet utilisateur peut avoir accès à ce cache de build. 0770 signifie que cet utilisateur et
n'importe qui dans le groupe peut avoir un accès en écriture au cache de construction. 0777 signifie que
n'importe qui peut avoir accès au cache de construction. Les chiffres octaux sensibles sont 7
(écrire), 5 (lire) ou 0 (aucun). 3 (écriture) ou 1 (lecture) est également possible, permettant
le cache à utiliser, mais pas à parcourir, c'est-à-dire qu'il serait plus difficile pour un
utilisateur malveillant pour trouver des noms de fichiers à manipuler.

Dans un groupe de caches de construction, chacun a sa propre valeur pour cela, vous pouvez donc appliquer
différentes autorisations d'écriture sur différents disques.

Si vous ne spécifiez pas les autorisations, vos autorisations umask au moment de la création
s'appliquent tout au long de la durée de vie du cache de génération.

espace extérieur plus propre, [option ...] /chemin/vers/cache
Nettoie le cache. Makepp ne supprime jamais les fichiers du cache de compilation ; C'est comme tu veux
pour supprimer les fichiers avec cette commande. Pour les caches multi-utilisateurs, le sysop peut le faire.

Seuls les fichiers avec un nombre de liens de 1 sont supprimés (car sinon, le fichier n'est pas
physiquement supprimé de toute façon - vous venez de décacher un fichier que quelqu'un est apparemment
toujours intéressé, donc quelqu'un d'autre pourrait l'être aussi). Les critères que vous donnez concernent
les fichiers mis en cache réels. Chaque fichier d'informations de construction sera supprimé lorsque son fichier principal le sera.
Aucun répertoire vide ne sera laissé. Indépendamment du nombre de liens et des options que vous
donner, tout fichier qui ne correspond pas à son fichier d'informations de construction sera supprimé, s'il est plus ancien
qu'une marge de sécurité de 10 minutes.

Les options suivantes prennent une spécification de temps comme argument. Les spécifications de temps commencent par
un "+" signifiant il y a plus longtemps, un "-" signifiant plus récemment ou rien de signifiant entre les
nombre que vous donnez, et un de plus. Les nombres, qui peuvent être fractionnaires, sont des jours par défaut.
Mais ils peuvent être suivis de l'une des lettres "w" (semaines), "d" (jours, valeur par défaut),
"h" (heures), "m" (minutes) ou "s" (secondes). Notez que les jours sont simplement 24 heures réelles
en ignorant tout changement entre l'heure d'été et d'hiver. Exemples:

1 il y a entre 24 et 48 heures
il y a 24h entre 24 et 25 heures
il y a 0.5j entre 12 et 36 heures
1w entre 7 et 14 fois il y a 24 heures
-2 il y a moins de 48 heures
+30m il y a plus de 30 minutes

Toutes les options suivantes sont combinées avec "et". Si vous voulez plusieurs ensembles de
combinaisons avec "ou", vous devez appeler cette commande à plusieurs reprises avec différents ensembles de
option. Faites d'abord ceux où vous attendez le plus de suppressions, puis les autres peuvent
Être plus rapide.

Options standard : "-A, --args-file, --arguments-file=nom de fichier, -v, --verbose"

-a spec
--une heure spec
--temps d'accès spec
La dernière fois que le fichier a été lu. Pour un fichier lié, cela peut arriver à tout moment.
Sinon, c'est la dernière fois que le fichier a été copié. Sur les systèmes mal comportés
il peut également s'agir de l'heure de la dernière sauvegarde sur bande ou de la création de l'index de recherche. Vous pourriez
essayez d'exclure le cache de telles opérations.

Certains systèmes de fichiers ne prennent pas en charge le champ atime, et même si le système de fichiers
fait, parfois les gens désactivent le temps d'accès sur leurs systèmes de fichiers car cela ajoute
beaucoup d'E/S disque supplémentaires qui peuvent être nuisibles sur les ordinateurs portables alimentés par batterie, ou dans
optimisation de la vitesse du disque. (Mais c'est potentiellement réparable -- voir le
commentaire UTIME_ON_IMPORT dans Mpp/BuildCache.pm.)

-b
--mélanger
--blend-groups
Habituellement chacun /chemin/vers/cache vous spécifiez traitera séparément le groupe de build
caches auxquels il appartient. Chaque groupe n'est traité qu'une seule fois, même si vous spécifiez
plusieurs chemins d'un même groupe. Avec cette option, vous mélangez temporairement tous
les groupes que vous spécifiez en un seul groupe.

Faire cela pour nettoyer peut avoir des effets indésirables, si vous pouvez créer un lien vers des liens symboliques,
car il peut migrer des membres d'un groupe à un autre. Ultérieure non mélangée
nettoie, peut alors les nettoyer prématurément du groupe d'origine.

-c spec
--cheure spec
--changer le temps spec
L'heure du dernier changement de l'inode du fichier. Dans une situation de liaison, cela pourrait être
le moment où le dernier utilisateur a recréé le fichier différemment, en coupant son lien vers
la cachette. Cela pourrait également être le temps que l'option "--set-user" ci-dessous a dû
changer d'utilisateur. Sur les systèmes bien comportés, cela pourrait également être le moment où le
la dernière sauvegarde sur bande ou création d'index de recherche a couvert ses marques en réinitialisant le
à l'heure.

-m spec
--mtime spec
--heure-de-modification spec
L'heure de la dernière modification du fichier. Comme expliqué ailleurs, il est déconseillé
pour que makepp mette à jour un fichier. Donc, la dernière modification sera généralement le temps
de création. (Mais à l'avenir, makepp peut éventuellement mettre à jour le mtime lorsque
suppression de fichiers. C'est pour que des liens sur des systèmes de fichiers ou des copies intemporelles puissent être
suivi.)

-g groupe
--newgrp=groupe
--nouveau-groupe=groupe
Définissez l'identifiant de groupe effectif et réel sur le groupe (nom ou numérique). Seule la racine peut être
capable de faire cela. Cela est nécessaire lorsque vous utilisez des caches de build groupés et que vous
fournir un accès en écriture aux caches en fonction de l'ID de groupe. Ce ne sera généralement pas
le groupe root et donc la réplication créerait des répertoires non inscriptibles sans cela
option.

Cette option est nommée d'après l'utilitaire équivalent "newgrp" qui, hélas, ne peut pas facilement
être utilisé dans des tâches "cron" ou des configurations similaires.

-i
--build-info
--build-info-check
Vérifiez que les informations de build correspondent au membre. Ce test est assez cher donc
vous pourriez envisager de ne pas donner cette option pendant la journée.

-l
--symlink-check
--vérification des liens symboliques
Cette option fait "propre" lire chaque lien symbolique qui n'a pas de disque dur externe
liens pour vérifier qu'il pointe vers le membre souhaité. Comme c'est un peu
cher, il est suggéré de ne le faire que la nuit.

-M spec
--in-mtime spec
--heure de modification entrante spec
L'heure de la dernière modification des fichiers dans le répertoire entrant. Ce répertoire est
utilisé pour les fichiers temporaires avec des noms spécifiques au processus qui peuvent être écrits sans
accès concurrent puis renommé dans la partie active du cache de manière atomique.
Normalement, les fichiers ne vivent ici que le temps nécessaire pour les écrire, mais ils peuvent
devenir orphelin si le processus qui les écrit se termine anormalement avant lui
peut les supprimer. Cette partie du cache est nettoyée en premier, car le lien compte
dans la partie active du cache peut être mal affecté par des fichiers orphelins.

Le timespec pour "--incoming-modification-time" doit commencer par "+", et les valeurs par défaut
à "+2h" (les fichiers d'au moins 2 heures sont supposés être orphelins).

-w
--jours ouvrés
Cela influence la façon dont les options de temps comptent. Les week-ends sont ignorés, comme s'ils
n'étaient pas là. Une exception est si vous donnez cette option un week-end. Alors ça
le week-end compte normalement. Vous pouvez donc l'utiliser dans les tâches cron qui s'exécutent à partir de mardi
au samedi. L'heure d'été est ignorée. Donc les week-ends d'été peuvent aller du samedi
1:00 au lundi 1:00, ou les week-ends d'hiver de l'hémisphère sud du vendredi 23:00 à
Dimanche 23h00 ou quel que soit votre fuseau horaire change l'heure. Les vacances sont aussi
pas pris en compte.

-p code perl
--perl=code perl
--prédicat=code perl
A FAIRE : adaptez cette description aux changements de groupe !

C'est le couteau de l'officier suisse. Les code perl est appelé dans le contexte scalaire une fois
pour chaque entrée de cache (c'est-à-dire à l'exclusion des répertoires et des fichiers metainfo). Il est
appelé dans une fonction "File::Find" "voulu", alors voyez-y les variables que vous pouvez
utilisation. Un "lstat" a été effectué, vous pouvez donc utiliser le descripteur de fichier "_".

If code perl renvoie "undef" c'est comme si ce n'était pas là, c'est l'autre
les options décident. S'il renvoie true, le fichier est supprimé. S'il retourne faux, le
fichier est conservé.

-s spec
--Taille spec
La spécification de la taille du fichier fonctionne exactement comme les spécifications de temps, avec "+" pour
plus grand que ou "-" pour plus petit que, sauf que les unités doivent être "c" (octets, le
par défaut), "k" (kilooctets), "M" (mégaoctets) ou "G" (gigaoctets).

-u utilisateur
--utilisateur=utilisateur
--set-utilisateur=utilisateur
Cette option est très différente. Il ne dit pas quand supprimer un fichier. Au lieu de cela
s'applique aux fichiers qui ne sont pas supprimés. Notez que sur de nombreux systèmes, seul root
est autorisé à définir l'utilisateur d'un fichier. Voir sous « Avertissements sur l'utilisation de build
caches" pourquoi vous devrez peut-être changer la propriété d'un utilisateur neutre si vous utilisez
quotas de disque.

Cette stratégie ne fonctionne que si vous pouvez faire confiance à vos utilisateurs pour ne pas subvertir la version
cache pour stocker des fichiers arbitraires (c'est-à-dire non liés au développement) au-delà de leur quota de disque.
La propriété du fichier de métadonnées associé est conservée, vous pouvez donc toujours voir
qui a mis en cache un fichier. Si vous avez besoin de cette option, vous devrez peut-être lui donner plusieurs
fois pendant la journée.

Il existe différentes stratégies possibles, en fonction de l'espace dont vous disposez et de
si le cache de génération contient des fichiers liés ou si les utilisateurs n'ont que des copies.
Plusieurs stratégies peuvent être combinées, en les appelant les unes après les autres ou à différents
fois. La commande "show" est destinée à vous aider à trouver une stratégie appropriée.

Une exécution nocturne (du mardi au samedi) peut spécifier "--atime +2" (ou "--mtime"
si vous n'avez pas le temps), en supprimant tous les fichiers que personne n'a lus depuis deux jours.

Si vous utilisez des liens, vous pouvez également empêcher une croissance inutile rapide qui se produit lorsque
les changements d'en-tête successifs, qui ne sont jamais contrôlés par la version, conduisent à de nombreux objets
étant rapidement créé. Quelque chose comme une course horaire avec "--mtime=-2h --ctime=+1h"
pendant la journée, attrapera les gars que le créateur a supprimés en moins d'une heure,
et personne d'autre n'en a voulu depuis.

montrer [option ...] /chemin/vers/cache
Il s'agit d'une sorte de commande récursive "ls -l" ou "stat", qui affiche le propriétaire d'origine
aussi, lorsque le propriétaire du fichier mis en cache a été modifié et que le fichier de métadonnées
conserve le propriétaire d'origine (selon "clean --set-user"). Il montre les fichiers donnés, ou
le tout dans les répertoires donnés.

Les champs sont, sous la forme courte standard et la forme longue verbeuse :

MODE, mode
Le mode octal du fichier mis en cache, qui est généralement tel qu'il a été mis, moins le
écrire des bits.

EL, liens externes
Le nombre de liens durs externes qu'il y a vers tous les membres du groupe combinés.
Ce n'est que lorsqu'il est égal à 0 que le fichier est éligible pour le nettoyage.

C, copies (uniquement pour les caches de build groupés)
Le nombre de copies du fichier identique, dans tous les caches de build. Idéalement ce
en est un sur les systèmes qui permettent des liens durs vers des liens symboliques, mais cela peut
temporairement pas possible, alors qu'il existe des liens externes vers plus d'une copie
(auquel cas nous perdrions le nombre de liens si nous le supprimions.

S, liens symboliques (uniquement pour les caches de build groupés)
Le nombre de liens symboliques entre les caches de build. Idéalement, c'est le nombre de
construire des caches moins un sur les systèmes qui permettent des liens durs vers des liens symboliques.
Mais comme expliqué pour le champ précédent, il peut y avoir plus de copies que nécessaire,
et donc moins de liens.

UID Le propriétaire du fichier mis en cache. Cela peut être modifié avec l'option "clean --user".

BI-UID
Le propriétaire du fichier d'informations de construction. Ceci n'est pas modifié par clean, permettant de voir
qui a créé le fichier en premier.

TAILLE
La taille (d'une copie) en octets.

une heure, mheure, cheure
Dans la forme longue et verbeuse, vous obtenez le temps d'accès (lecture) au fichier, la modification
l'heure et l'heure de changement d'inode (par exemple lorsqu'un utilisateur a supprimé son lien externe vers
le fichier mis en cache). Dans la forme standard courte, vous n'obtenez qu'une des trois fois
dans trois colonnes distinctes :

AD, MD, CD
Le jour de la semaine de l'accès, de la modification ou du changement d'inode.

ADATE, MDATE, CDATE
La date de l'accès, de la modification ou du changement d'inode.

ATIME, MTIME, CTIME
L'heure du jour de l'accès, de la modification ou du changement d'inode.


Le chemin complet du fichier mis en cache, y compris la clé, à partir de la racine du cache.

Avec "-v, --verbose" les informations affichées pour chaque commande vous permettent d'obtenir un
impression quelles options donner à la commande "clean". Les heures sont affichées en
forme lisible, ainsi que le nombre de jours, d'heures ou de minutes l'âge de ce fichier
vient de dépasser. Si vous doublez l'option, vous obtenez en plus les informations pour chaque
membre du groupe.

Options standard : "-A, --args-file, --arguments-file=nom de fichier, -f, --force, -o,
--output=nom de fichier, -O, --outfail, -v, --verbose"

-a
--une heure
--temps d'accès
Affiche l'heure d'accès au fichier, au lieu de l'heure de modification du fichier en mode non-verbeux.

-b
--mélanger
--blend-groups
Habituellement chacun /chemin/vers/cache vous spécifiez traitera séparément le groupe de build
caches auxquels il appartient. Chaque groupe n'est traité qu'une seule fois, même si vous spécifiez
plusieurs chemins d'un même groupe. Avec cette option, vous mélangez temporairement tous
les groupes que vous spécifiez en un seul groupe.

-c
--cheure
--changer le temps
Afficher l'heure de changement des informations sur l'inode, au lieu de l'heure de modification du fichier en non-verbeux
mode.

-d
--supprimable
Afficher uniquement les fichiers effaçables, c'est-à-dire ceux avec un nombre de liens externes de 0.

-p modèle
--motif=modèle
Patron de Couture est un modèle de nom de fichier de style bash (c'est-à-dire ?, *, [], {,,}) comparé à
les noms des membres après le trait de soulignement les séparant de la clé.

-s liste
--tri=liste
En mode non verbeux, modifiez l'ordre de tri. La liste est insensible à la casse
ordre des titres de colonnes séparés par des virgules ou des espaces. Il existe deux cas particuliers :
"member" ne considère que les noms après la clé, c'est-à-dire les noms de fichiers tels qu'ils sont
en dehors de la cache. Et il y a un nom spécial "âge", qui regroupe
la date et l'heure sont affichées. Cette option est définie par défaut sur « membre,âge ».

Si vous avez un énorme cache dont le tri prend trop de temps ou nécessite plus
mémoire que vos processus ne sont autorisés, vous pouvez ignorer le tri en donnant une valeur vide
liste.

stats [option ...] /chemin/vers/cache
Cela génère plusieurs tableaux de statistiques sur le contenu du cache de génération. Chaque tableau
est divisé en trois groupes de colonnes. La première colonne varie pour chaque table et est la
en-tête de ligne. Les deux autres groupes se rapportent à la somme de TAILLE de fichiers et nombre de DES DOSSIERS
pour cette rubrique. Les répertoires et les fichiers d'informations de construction ne sont pas comptés, il s'agit donc d'un
un peu moins pour la taille que l'utilisation réelle du disque et environ la moitié pour le nombre de fichiers.

Chacun de ces deux derniers groupes se compose de trois paires de colonnes, une colonne avec une valeur,
et un pour le pourcentage du total que cette valeur représente. La première paire montre
soit la taille des fichiers, soit le nombre de fichiers. Les deux autres paires montrent le
CUMULation, une fois du plus petit au plus grand et une fois dans l'autre sens.

Les trois premiers tableaux, avec une première colonne de AD, CD or MD afficher les temps d'accès, inode
horaires de changement ou horaires de modification regroupés par jours. Les jours sont en fait des blocs de 24 heures
compter à rebours à partir de l'heure de début de la commande stats. La ligne "0" du premier
le tableau affichera ainsi la somme des tailles et le nombre de fichiers accédés en moins d'une journée
depuis. Si aucun fichier n'a été accédé, il n'y aura pas de ligne "0". Rangée "1" dans le troisième
le tableau affichera les fichiers modifiés (c'est-à-dire écrits dans le cache de construction) entre 24 et 48
il y a des heures.

Le tableau suivant, EL, affiche les liens externes, c'est-à-dire combien d'arbres de construction partagent un fichier à partir de
le cache de construction. Il s'agit d'une mesure de l'utilité du cache de construction. Hélas il n'y a que
fonctionne lorsque les développeurs ont un cache buld sur leur propre disque, sinon ils doivent copier
qui ne laisse aucune trace mondiale. Plus le contenu a un plus grand nombre de liens externes, le
plus grand l'avantage du cache de construction.

La table d'à côté, encore EL, affiche les mêmes informations que la précédente, mais pondérées
par le nombre de liens externes. Chaque octet ou fichier avec un nombre de liens externes d'un
compte pour un. Mais si le compte est de dix, les valeurs sont comptées dix fois. C'est pourquoi
les en-têtes deviennent *TAILLE et *DES DOSSIERS. Il s'agit d'une valeur hypothétique, montrant comment
beaucoup d'utilisation du disque ou combien de fichiers il y aurait si les mêmes arbres de construction avaient tous été utilisés
pas de cache de construction.

Encore un tableau, C: S copies vers des liens symboliques, ne concerne que les caches groupés. Idéalement tout
les membres existent dans une copie et un lien symbolique de moins qu'il n'y a de caches dans le groupe.
Les liens symboliques restent « 0 » jusqu'à ce que le nettoyage soit répliqué. Il peut y avoir plus d'un exemplaire,
si soit plusieurs personnes ont créé le même fichier avant sa réplication, soit si
la réplication a migré le fichier vers un disque préféré, mais le fichier d'origine était toujours dans
utilisation. Les copies superflues deviennent des liens symboliques lorsque le nettoyage constate qu'elles n'en ont plus
Liens externes.

Options standard : "-A, --args-file, --arguments-file=nom de fichier, -v, --verbose"

-h
--les heures
Affichez les trois premiers tableaux avec une granularité beaucoup plus fine. Les en-têtes de colonnes
changer en AH, CH or MH il se doit !

-p modèle
--motif=modèle
Patron de Couture est un modèle de nom de fichier de style bash (c'est-à-dire ?, *, [], {,,}) comparé à
les noms des membres après le trait de soulignement les séparant de la clé. Toutes les statistiques
sont limités aux fichiers correspondants.

Avertissements de travail avec construire caches
Les caches de construction ne fonctionneront pas correctement dans les circonstances suivantes :

· Si la commande que makepp exécute pour créer un fichier en fait uniquement mises à jour le fichier et
ne le construit pas frais, alors vous devriez ne pas utiliser un cache de construction. (Un exemple est un
commande pour mettre à jour un module dans une bibliothèque statique (un fichier archive, ou un fichier avec un
extension de .a). Comme expliqué dans makepp_cookbook, sur les machines modernes, il est presque
toujours une mauvaise idée de mettre à jour un fichier d'archive - il vaut mieux le reconstruire à partir de zéro
à chaque fois pour diverses raisons. C'est encore une autre raison de ne pas mettre à jour un
archive.) La raison en est que si le cache de construction se trouve sur le
même système de fichiers, makepp crée un lien physique plutôt que de copier le fichier. Si vous alors
modifier par la suite le fichier, le fichier que makepp a dans le cache de construction sera
en fait être modifié, et vous pourriez potentiellement bousiller la compilation de quelqu'un d'autre.
En pratique, makepp peut généralement détecter qu'un fichier a été modifié depuis qu'il a été
placé dans le cache de construction et il ne l'utilisera pas, mais parfois il peut ne pas en fait
détecter la modification.

· Pour .o cela peut être légèrement faux, car ils peuvent (selon le compilateur
et niveau de débogage) contiennent le chemin d'accès à la source à partir de laquelle ils ont été créés. Cela peut faire
débogage dur. Le débogueur peut vous obliger à modifier la copie du créateur d'origine du
source, ou peut même ne pas trouver le fichier, si le créateur n'en a plus de copie. Makepp
peut un jour offrir une option pour patcher le chemin, ce qui signifiera bien sûr une copie,
au lieu d'un lien efficace.

· Tout autre fichier contenant un chemin codé ne doit pas être placé dans un cache de construction
(si vous partagez votre cache de build entre plusieurs hiérarchies de répertoires ou plusieurs
développeurs). Dans ce cas, le résultat d'une construction dans un répertoire différent n'est pas le
comme s'il se trouvait dans le même répertoire, donc tout le concept du cache de construction est
n'est pas applicable. Ce n'est pas grave si vous spécifiez le chemin du répertoire sur la ligne de commande, comme
ce:

&echo chemin_prog=$(PWD) -o $(sortie)

car alors la ligne de commande sera différente et makepp ne tirera pas incorrectement le
fichier hors du cache de construction. Mais si la ligne de commande n'est pas différente, alors il
pourrait être un problème. Par exemple,

echo prog_path=`pwd` > $(sortie)

ne fonctionnera pas correctement.

· Lors de l'utilisation de liens et avec de nombreux développeurs actifs du même projet sur le même disque,
les caches de construction peuvent économiser beaucoup d'espace disque. Mais en même temps pour les utilisateurs individuels
l'inverse peut aussi être vrai :

Imagine Chang est le premier à faire une version complète. Arrive Ching et obtient un lien vers
tous ces fichiers. Chang effectue des changements fondamentaux conduisant à ce que la plupart des choses soient
reconstruit. Il les enregistre, Chong les vérifie et obtient des liens vers le cache de construction.
Chang effectue à nouveau des modifications, conduisant à un troisième ensemble de fichiers.

Dans ce scénario, quelle que soit la stratégie de nettoyage que vous utilisez, aucun fichier ne sera supprimé,
car ils sont tous encore utilisés. Le problème est qu'ils appartiennent tous à Chang,
ce qui peut lui faire atteindre son quota de disque, et il n'y a rien qu'il puisse faire à ce sujet sur
la plupart des systèmes. Voir la commande "clean --set-user" sous "Comment gérer un cache de construction"
pour savoir comment l'administrateur système pourrait changer les fichiers en un propriétaire de cache sans quota.

· Si vous utilisez des signatures d'horodatage/taille pour vérifier la cible et sa construction
info (par défaut), il est alors possible d'obtenir un alias de signature, dans lequel non-
les fichiers correspondants ne seront pas détectés. Par exemple, la valeur d'informations de build MD5_SUM
peut ne pas correspondre à la somme de contrôle MD5 de la cible. Ce n'est généralement pas un problème, car
en raison du fait que les clés du cache de construction correspondent, la cible dans le cache de construction
est substituable à la cible qui aurait correspondu au fichier d'informations de construction.
Cependant, si vous avez des actions de règle qui dépendent des informations de build, cela pourrait vous
dans les ennuis (alors ne faites pas ça). Si cela vous inquiète, utilisez le --md5-check-bc
option.

Concurrent accès
Les caches de build doivent prendre en charge l'accès simultané, ce qui implique que l'implémentation doit
être tolérant envers les races. En particulier, un fichier peut vieillir (supprimer) entre le moment
makepp décide d'importer une cible et l'heure à laquelle l'importation se termine.

De plus, certaines personnes utilisent des caches de build sur NFS, ce qui n'est pas forcément cohérent. Dans
en d'autres termes, l'ordre de création et de suppression des fichiers par le rédacteur sur un hôte ne sera pas
correspondent nécessairement à l'ordre vu par un lecteur sur un autre hôte, et donc des courses ne peut pas
être résolu en accordant une attention particulière à l'ordre des opérations sur les fichiers. (Mais il y a
généralement un délai d'expiration du cache NFS d'environ 1 minute, ce qui garantit que les écritures ne prendront pas
plus long que ce laps de temps pour se propager à tous les lecteurs. De plus, généralement dans
pratiquez au moins 99% des écritures sont visibles partout en 1 seconde.) Pour cette raison,
nous devons tolérer le cas où la cible mise en cache et son fichier d'informations de construction semblent ne pas
correspondre. De plus, il existe une course particulière qui peut se produire lorsqu'un fichier est
simultanément vieilli et remplacé, dans lequel les fichiers ne correspondent pas même après le NFS
vidages de cache. Cela semble inévitable.

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