makepp_repositories - En ligne dans le Cloud

PROGRAMME:

Nom

makepp_repositories -- Comment utiliser les référentiels pour les versions de variantes, pour maintenir un
ensemble central de sources, et d'autres choses

DESCRIPTION

A dépôt est un répertoire ou une hiérarchie de répertoires en dehors du répertoire par défaut qui
contient les fichiers dont le makefile a besoin dans l'arborescence de répertoires actuelle. Makepp peut
lier automatiquement les fichiers du référentiel dans l'arborescence de répertoires actuelle s'ils sont
nécessaire. Les référentiels offrent des fonctionnalités similaires à la variable "VPATH", mais (contrairement à
"VPATH" dans d'autres versions de make) vous n'avez rien à faire de spécial à votre makefile
pour les amener au travail.

Les référentiels sont spécifiés avec l'option de ligne de commande "-R" ou "--repository" ou avec le
instruction "repository" dans le makefile. Notez que si vous avez l'habitude d'appeler makepp
dans différents sous-répertoires de votre arbre de construction, il est facile de réimporter accidentellement un
référentiel ailleurs. Par mesure de protection, si vous utilisez Fichier RootMakepp, faire
refusera de démarrer s'il en trouve un au-dessus ou en dessous de l'endroit où il serait importé.

C'est quelque peu comparable aux systèmes de fichiers d'union du système d'exploitation (unionfs...)
le répertoire courant est comme la couche inscriptible de plus haut niveau. Tous les référentiels sont comme
couches inférieures en lecture seule.

Les référentiels sont utiles dans plusieurs situations différentes :

· Lorsque vous souhaitez placer votre objet et vos fichiers exécutables dans un répertoire séparé, mais
le makefile est écrit pour les placer dans le même répertoire que les sources.

· Lorsque vous voulez construire le même programme de deux manières différentes (par exemple, avec deux
ensembles d'options de compilation, ou pour deux architectures différentes).

· Lorsque vous n'avez pas accès en écriture à tout ou partie de l'arborescence des sources.

· Lorsque plusieurs développeurs travaillent sur le même projet, et qu'il existe une source commune
référentiel contenant toutes les sources du projet. Chaque développeur ne peut modifier que
les fichiers qu'il doit modifier dans son répertoire local sans affecter les autres
développeurs, et makepp récupérera automatiquement les fichiers non modifiés de la source
dépôt.

L'implémentation des référentiels par Makepp ne nécessite pas de réécriture des commandes de construction
du tout, contrairement (par exemple) aux référentiels en cons. Makepp met un lien symbolique dans le
répertoire où la commande l'attend. Tant que la commande ne fait pas référence à
répertoires absolus, la même commande shell fonctionnera avec les fichiers d'un référentiel.
Cela signifie qu'il fonctionne non seulement pour les commandes de compilation, mais pour tout type de commande que vous
pouvez penser à mettre dans votre makefile.

Makepp a un autre type de mécanisme appelé un construire cachette qui résout certains des mêmes
sortes de problèmes en tant que référentiels d'une manière différente. En fonction de votre problème, un build
le cache peut être plus utile qu'un référentiel. Voir makepp_build_cache pour plus d'informations sur
caches de construction et une comparaison des caches de construction et des référentiels.

Exemples
Les référentiels sont mieux expliqués par plusieurs exemples de ce que vous pouvez faire.

Différents compilation Options

Supposons que vous ayez un programme simple avec un makefile qui ressemble à ceci :

CLAGS = -O2
OBJETS = ao bo co
mon_programme : $(OBJETS)
cc $(entrées) -o $(sortie)

%.o : %c
cc $(CFLAGS) -c $(entrée) -o $(sortie)

Ce makefile place les fichiers "ao", "bo", "co" et "my_program" dans le même répertoire
comme fichiers sources.

Parfois, vous souhaitez placer les fichiers binaires dans un répertoire séparé. Par exemple, vous
peut construire votre programme sur plusieurs architectures différentes, et vous ne voulez pas que le binaire
fichiers sur une architecture à remplacer par les fichiers binaires sur l'autre. Ou vous pourriez
voulez faire une modification temporaire et recompiler sans effacer la compilation précédente
résultats. Sans référentiels, vous auriez à modifier votre makefile pour placer le
objets ailleurs.

Avec un référentiel, cependant, vous n'avez pas du tout à toucher à votre makefile. Prendre en compte
séquence de commandes suivante :

% cd mon_programme_source
% makepp # Construit en utilisant le makefile ci-dessus, et
# fichiers objets vont dans le répertoire
# mon_programme_source.
% cd ..
% mkdir binary-debug # Créer un répertoire propre pour construire le
% cd binary-debug # même programme avec des options différentes.
% makepp -R ../mon_programme_source CFLAGS=-g
# Maintenant, les objets entrent en débogage binaire.

La première commande makepp compile les fichiers sources avec optimisation et place les objets
dans le répertoire "my_program_source", car c'est ce que le makefile est censé faire
faire. Maintenant, nous voulons reconstruire le programme, mais nous voulons changer la valeur de "CFLAGS" en
compiler pour le débogage. Nous spécifions la nouvelle valeur de "CFLAGS" sur la ligne de commande, et nous
dites à makepp que le répertoire "my_program_source" est un référentiel en utilisant l'option "-R".

Chaque fois que makepp se rend compte qu'il a besoin d'un fichier qu'il n'a pas déjà en cours
répertoire, il regarde dans le référentiel. Dans ce cas, il recherche d'abord le makefile,
qui n'existe pas dans le sous-répertoire "binary-debug". Il crée donc un lien symbolique vers
à partir du makefile dans "my_program_source", puis lit dans le makefile. Puis il
remarque qu'il a besoin du fichier "ac" pour construire "ao", et donc il se lie dans "ac"
du référentiel. Si "ac" inclut des fichiers contenus dans "my_program_source", alors
ceux-ci seront également automatiquement liés. Remarque : ces liens sont utiles pour les choses
comme le débogage, mais si vous ne les aimez pas, "makeppclean -R" peut les supprimer.

L'exécution de la commande de construction dans "binary-debug" ne touchera aucun des fichiers dans
"mon_programme_source". Ainsi, à partir du même ensemble de fichiers source, vous disposez maintenant de deux
copies du programme, une compilée avec optimisation et une compilée pour le débogage. Et
cela s'est produit sans toucher du tout au makefile.

L'avantage d'utiliser des référentiels au lieu de simplement recompiler et écraser le
binaires d'origine est que maintenant si nous corrigeons nos bugs et voulons revenir à l'optimisé
version, nous n'avons pas à tout recompiler. Étant donné que les fichiers objets d'origine sont toujours
autour, et la plupart d'entre eux sont encore valides, nous pouvons gagner beaucoup de temps sur la recompilation.
Cela ne fait pas une grande différence lorsque seulement trois fichiers sources sont impliqués, mais pour un
une construction plus importante qui prend des minutes ou des heures à terminer, les économies de temps du programmeur et
la frustration peut être importante.

Reconstitution UN filet avec a mineur modifiant à le compilation commandes

Makepp ne récupère pas uniquement les fichiers sources du référentiel. Si les fichiers objet dans le
Le référentiel n'a pas besoin d'être reconstruit, il les utilisera. Par exemple, considérons un léger
modification du makefile ci-dessus :

CLAPET := -O2
A_CFLAGS := -O6 -funroll-boucles

OBJETS := ao bo co

mon_programme : $(OBJETS)
cc $(entrées) -o $(sortie)

%.o : %c
cc $(CFLAGS) -c $(entrée) -o $(sortie)

ao: ac
cc $(A_CFLAGS) -c $(entrée) -o $(sortie)

L'idée est que "ao" contient le code à temps critique, il est donc compilé avec des
optimisation que le reste des objets. Supposons maintenant que nous voulions tester à quel point les différences
le timing est avec différentes options de compilation. Un référentiel peut également vous aider :

% cd mon_programme_source
% makepp # Construit en utilisant le makefile ci-dessus, et
# fichiers objets vont dans le répertoire
# mon_programme_source.
% cd ..
% mkdir no-unrolling # Créer un répertoire propre pour construire le
% cd no-unrolling # même programme avec différentes options.
% makepp -R ../mon_programme_source A_CFLAGS=-O2
% cd ..
% time no-unrolling/my_program # Comparez les deux versions du programme.
% de temps mon_programme_source/mon_programme

Makepp procède comme avant, en liant une copie du makefile puis en examinant l'objet
des dossiers. Maintenant, seul le module "ao" a besoin d'être recompilé, car les options pour "bo" et "co"
n'ont pas changé. Makepp remarque qu'il peut utiliser "bo" et "co" du référentiel, donc
il ne fait que les relier. Cependant, il recompilera "ao" dans le répertoire "no-unrolling".
Une fois la compilation terminée, les deux versions différentes du programme peuvent être
étalonné.

Reconstitution avec a mineur modifiant à le source

Supposons maintenant que nous voulions apporter une modification à "ac" et comparer le programme avant et après
le changement. Les référentiels peuvent à nouveau vous aider. Considérez cette séquence de commandes :

% mkdir modifié-a
% cp ma_source_programme/ac modifié-a
% cd modifié-a
% emacs ac # Apportez quelques modifications uniquement à ce module.
% makepp -R ../mon_programme_source

Ici, nous avons créé un nouveau répertoire qui ne contient que le fichier source unique que nous voulons
modifier. Makepp prend maintenant "ac" du sous-répertoire "modified-a", mais utilise les copies de
"b" et "c" du répertoire "my_program_source". Sans changer le binaire
fichiers dans "my_program_source", nous avons créé une copie séparée du programme qui
intègre nos modifications apportées à "ac". S'il y a d'autres développeurs utilisant les sources dans
"my_program_source", ils ne seront pas affectés par nos modifications.

Les référentiels peuvent ainsi être utilisés comme un moyen rapide de construire des variantes d'un programme, sans
ajouter des conditions compliquées au makefile. Aucun des fichiers de l'original
répertoire sont modifiés ; ils sont utilisés au besoin.

En utilisant a annuaire hiérarchie

Un référentiel n'est en fait pas qu'un seul répertoire, c'est toute une hiérarchie de répertoires.
Supposons que vous utilisez /notre/bibliothèque en tant que référentiel. Maintenant /notre/bibliothèque peut bien contenir de nombreux
sous-répertoires, par exemple, /notre/bibliothèque/gui et /notre/bibliothèque/réseau. Considérez cette commande :

% makepp -R /notre/bibliothèque

Toutes les commandes du makefile qui font référence à des fichiers du répertoire ./réseau sera en fait
obtenir des fichiers de /notre/bibliothèque/réseau, et de même pour ./gui. Makepp automatiquement
crée tous les répertoires qui existent dans le référentiel mais pas dans le répertoire actuel.

Enchaînement à tout endroit in le filet Système

Tous les exemples ci-dessus montrent des fichiers d'un référentiel en cours de liaison dans le
répertoire ou ses sous-répertoires, mais vous pouvez en fait demander à makepp de les lier à n'importe quel endroit
dans le système de fichiers auquel vous avez accès en écriture. Cela se fait en spécifiant
"-R nouvel-emplacement=ancien-emplacement".

Par exemple, il est parfois un peu fastidieux de taper ce qui suit :

mkdir alternative-build
cd alternative-build
makepp -R ..

Vous pouvez tout faire avec une seule commande, comme ceci :

makepp -R alternate-build=. -F version alternative

"-F" ou "-makeppfile" change dans ce répertoire avant de charger le makefile. Vous devez
spécifiez "-R" avant "-F". Notez que cet exemple place le nouvel arbre de construction à l'intérieur du
dépôt. Cela ne fonctionnera pas si vous utilisez un Fichier RootMakepp parce que makepp protège
contre les arbres imbriqués. Ce n'est pas non plus une bonne idée si vous utilisez **, parce que si jamais vous construisez
dans le référentiel, il trouvera également les fichiers édités et générés dans cette sous-arborescence.

L'attribution d'un emplacement différent dans le système de fichiers peut également être utile pour des
builds, où il y a plusieurs sous-répertoires de bibliothèque. Par exemple, voici une commande que je
ont utilisé pour construire des variantes d'un de mes programmes :

% makepp -R test-build/seescape=/src/seescape \
-R test-build/HLib=/src/HLib \
-R test-build/H5pp=/src/H5pp \
-R qwt=/src/external_libraries/qwt \
-F test-build/seescape

Cette commande charge les fichiers de quatre référentiels différents, puis les cds vers le
./test-build/seescape répertoire et y exécute le makefile. Les fichiers contenus dans le
arborescence de répertoires commençant par /src/seescape sont liés à ./test-build/seescape. En
en d'autres termes, makepp liera temporairement le fichier /src/seescape/gui/image_canvas.cxx à
./test-build/seescape/gui/image_canvas.cxx lorsque cela est nécessaire. Cette commande fonctionnera même
si le répertoire "test-build" n'existe pas encore ; makepp le créera pour vous. (Mais toi
doit spécifier les options "-R" avant l'option "-F" sur la ligne de commande.)

Multiple équivalent code source

Supposons que votre projet soit maintenu par plusieurs groupes assez autonomes. Tu pourrais en avoir un
référentiel complet avec toutes les sources telles qu'elles sont en production ou au moins
testé avec succès. Chaque groupe peut avoir un référentiel presque vide avec (une partie de) le
même structure, contenant les fichiers que les membres du groupe ont fini de développer.

Les répertoires actuels des développeurs contiendront les fichiers sur lesquels ils travaillent encore. Le groupe
le référentiel sera le premier donné et le référentiel de production le dernier, de sorte que
il fournit les fichiers introuvables dans le référentiel du groupe :

$ makepp -R/chemin/vers/groupe/dépôt -R/chemin/vers/production/dépôt

Comme c'est probablement assez statique pour ce répertoire, vous voudrez peut-être mettre un fichier
.makepprc à sa racine avec le contenu suivant :

-R/chemin/vers/groupe/dépôt -R/chemin/vers/production/dépôt

Ou, en supposant qu'il a un chemin fixe, vous pouvez écrire dans votre makefile :

référentiel /chemin/vers/production/référentiel

et, parce que les options sont vues avant que les makefiles ne soient lus, vous pouvez alors appeler simplement

$ makepp -R/chemin/vers/groupe/dépôt

Dépôts as fixé partie of votre construire Système

Si vous savez que vous utilisez toujours un référentiel, vous pouvez utiliser le "référentiel" ou "vpath"
déclarations dans votre makefile.

Avertissements avec code source
Quand le Gauche obtenez in le manière

Pour trouver votre chemin dans votre hiérarchie de fichiers et pour permettre au débogueur de trouver le
sources, il est utile d'avoir les liens utilisés lors de la construction. Mais quand vous voulez éditer un
ou resynchronisez-le avec votre contrôle de version, les liens peuvent gêner. C'est-à-dire
car le système parcourt le lien et écrit dans le fichier du référentiel. Sauf si
c'est votre référentiel personnel utilisé uniquement pour séparer les choses, ce n'est peut-être pas ce que vous
vouloir.

Afin de se prémunir contre l'écrasement par inadvertance des fichiers publics, il est suggéré de
sources dans le référentiel non inscriptibles. Il se peut même qu'il ne suffise pas de supprimer l'écriture
peu, car un système de contrôle de version qui insiste pour que vous verrouilliez les fichiers pour l'édition
peut également le faire, mais rendre temporairement le fichier accessible en écriture lors de sa resynchronisation. Si c'est
Dans votre cas, le référentiel devrait en fait appartenir à un autre utilisateur.

Il existe quelques tactiques pour surmonter cela :

· Conservez les sources que vous éditez dans un référentiel, séparé de votre arbre de construction. N'importe quand
vous placez un fichier, qui a été précédemment récupéré à partir d'un autre référentiel, dans ce
éditant le référentiel, makepp le remarquera et le récupérera à partir de là, à condition que ce soit le
premier référentiel que vous spécifiez.

· N'oubliez pas de supprimer tout fichier avant de créer une copie pour l'écriture. Si vous suivez le
suggestion de sauvegarde ci-dessus, oublier de le faire donnera un message d'erreur lorsque
l'écriture. Pour vous aider, la fonction suivante "delink" remplacera un lien par une copie
du fichier lié. La première variante est pour toutes sortes de coquillages Bournish, la seconde
un pour csh (ou au moins tcsh) :

$ delink() { { rm $1 && cat >$1; } <$1 ; }
% alias delink '( rm \!:1 && cat >\!:1; ) <\!:1'

· Si vous sentez que vous n'en avez pas besoin, vous pouvez les supprimer tous, quand vous le souhaitez, par exemple
après chaque exécution de makepp, éventuellement en arrière-plan (forme courte ou longue):

makeppclean --recurse --only-repository-links
mppc -rR

Ne pas construire in a dépôt pendant utilisé

Un référentiel est destiné à être en lecture seule lorsqu'il est utilisé comme référentiel. Makepp va
pas fonctionner correctement si vous modifiez des fichiers dans votre référentiel au cours d'une construction.
Les builds nocturnes peuvent vous convenir, si personne d'autre n'utilise le référentiel à ce moment-là. Avant
il démarre la construction, makepp obtient une liste de tous les fichiers qui existent dans le référentiel, et
ne met jamais à jour sa liste, sauf pour les fichiers qu'il s'attend à voir apparaître.

Si vous avez besoin d'un référentiel qui change au fur et à mesure que vous construisez, vous voudrez peut-être considérer makepp
mécanisme de cache de construction (voir makepp_build_cache). Alternativement, vous pouvez utiliser un « pauvre homme
repository": vous pouvez mettre des règles explicites dans votre makefile pour créer les liens symboliques, comme
ce:

%.c : $(directory_I_wish_was_a_repository)/%.c
&ln -fs $(entrée) $(sortie)

Cela ne fonctionne que pour les fichiers source ; vous ne pouvez pas facilement l'utiliser pour lier un fichier s'il est
déjà construit dans le référentiel, mais construisez-le ici s'il n'est pas déjà construit, car il
n'est autorisé qu'à être une façon de créer un fichier.

Utilisez le uniquement relatif noms de fichiers

Les référentiels fonctionnent de manière totalement transparente if le fichiers make utilisé uniquement relatif noms de fichiers.
Dans l'exemple ci-dessus, ce n'est pas grave si le makefile dans /src/seescape désigne ../HLib, Mais l'
la commande ci-dessus ne fonctionnera pas comme prévu si elle fait référence à /src/HLib. Si vous devez utiliser
noms de fichiers absolus, vous pouvez les mettre dans des variables make, puis les remplacer sur le
ligne de commande, comme ceci :

% makepp -R test-build/seescape=/src/seescape SEESCAPE=/home/holt/test-build/seescape \
-R test-build/HLib=/src/HLib HLIB=/home/holt/test-build/HLib \
-R test-build/H5pp=/src/H5pp H5pp=/home/holt/test-build/H5pp \
-R qwt=/src/external_libraries/qwt QWT=/home/holt/test-build/qwt \
-F test-build/seescape

Ce qui précède fonctionnera tant que le répertoire "HLib" est appelé "$(HLIB)" dans tous les
makefiles. Notez que vous devez spécifier des chemins absolus pour les répertoires, car
makepp sur "test-build/seescape" avant de lire le makefile. Cela conduit à une longue et
commandes make compliquées ; utilisez des chemins relatifs lorsque cela est possible.

Makepp doit savoir à propos tous dépendances

Les référentiels ne fonctionneront pas s'il existe des dépendances cachées que makepp ne connaît pas
À propos. (En fait, faire une construction à l'aide de référentiels est un moyen de vérifier les oublis
dépendances. Mais, juste pour cette vérification, ne le combinez pas avec un cache de construction, car
y chercher quelque chose, au lieu de le construire, pourrait cacher une dépendance oubliée.)
Parfois, ces dépendances peuvent être assez subtiles. Par exemple, le libtool la commande sera
non seulement créer des fichiers ".lo" et ".la" comme indiqué sur la ligne de commande, mais il peut également
créez un sous-répertoire appelé ".libs" qui contient les fichiers objets réels. Pour prévenir
erreurs de construction, makepp refuse de lier un fichier ".la" à partir d'un référentiel. Espérons que dans
le futur libtool sera mieux supporté.

De nombreuses dépendances cachées liées à la compilation sont détectées par le scanner de ligne de commande.
Si votre compilateur utilise les drapeaux de compilation Unix communs (par exemple, "-I", "-D", etc.), alors
makepp déterminera généralement où se trouvent tous vos fichiers d'inclusion. Vous devrez peut-être être
attention si vous avez des scripts maison qui créent des fichiers que makepp ne connaît pas
À propos. Pour des builds corrects, il est extrêmement important de lister tous cibles et dépendances
(ou les déterminer automatiquement en scannant).

Putting absolu noms de fichiers développement tout proche.

Les référentiels ne fonctionneront pas non plus si l'un des fichiers créés contient des noms de fichiers absolus dans
(par exemple, si l'une de vos commandes de construction écrit un nom de fichier absolu). Par exemple,
il s'avère que les fichiers ".la" produits par libtool avoir cette propriété. (Si vous regardez
le contenu du fichier ".la" vous verrez que la liste des dépendances contient des valeurs absolues
noms de fichiers.) Afin de résoudre ce problème particulier, makepp ne liera pas les fichiers ".la"
à partir d'un référentiel ; il insistera pour les reconstruire.

Éviter les lien in inutile répertoires

Les référentiels peuvent être lents au démarrage et utiliser beaucoup de mémoire s'il y a beaucoup de
fichiers inutiles dans le référentiel. Par exemple, si vous utilisez un HTML automatique
générateur de documentation qui crée des milliers de fichiers ".html" à partir de votre code source, vous
peut ne pas vouloir les mettre dans un sous-répertoire d'un répertoire utilisé comme référentiel.
Il est préférable de les placer entièrement dans une arborescence de répertoires différente, de sorte que le référentiel
mécanisme ne se chargera pas dans leurs noms.

Aussi Merci beaucoup Documents officiels

L'inconvénient des référentiels est que les liens symboliques, que le mécanisme de référentiel
utilise, sont des fichiers individuels (bien qu'ils n'utilisent presque pas d'espace disque). C'est différent du réel
liens, mais ceux-ci ne peuvent pas franchir les limites du système de fichiers. Dans les cas extrêmes, la présence de
de très nombreux liens symboliques peuvent conduire à l'épuisement du nombre de fichiers prévus (appelés
inodes), même s'il reste beaucoup d'espace. Dans ce cas, l'administrateur système aura besoin
pour régler le système de fichiers.

Primordial dépôt copies
Si vous apportez des modifications à un fichier localement, makepp le réalisera normalement et
recompiler le fichier en utilisant la copie locale plutôt que la copie du référentiel.

Si vous utilisez un référentiel pour maintenir une base de code centrale et que vous avez des développeurs
travailler sur des copies locales qui ne contiennent que les fichiers qu'ils ont modifiés, un problème qui
apparaît : que se passe-t-il si un développeur souhaite supprimer un fichier de sa version locale mais que le
le référentiel le contient toujours ? Si le développeur supprime la copie locale, makepp
joyeusement mis dans la copie du référentiel, et la construction se déroulera comme si le fichier
existé.

Une technique (hélas pas pour l'utilisateur root) pour ce problème est de faire le fichier que vous voulez
à ne pas inclure dans le processus de construction illisible, comme ceci :

chmod a-rw fichier à exclure

Cela empêchera makepp de l'intégrer à partir du référentiel. Makepp comprend également
code spécial afin que les fichiers illisibles ne correspondent pas aux caractères génériques ou aux règles de modèle.

De même, pour empêcher makepp d'incorporer un sous-répertoire entier, créez un fichier local
répertoire qui porte le même nom mais qui n'est pas accessible en écriture. Si vous voulez que makepp ignore le
répertoire entièrement, puis rendez-le illisible aussi. (Les répertoires en lecture seule sont recherchés mais
les cibles qu'ils contiennent ne sont généralement pas construites.)

L'autre façon de procéder consiste à appeler makepp avec une ou plusieurs options d'exclusion :

mpp -R /chemin/vers/rep --dont-read=/chemin/vers/rep/file-to-be-excluded

Ne pas utilisé code source pour fichiers qui Vous pouvez changement!
N'essayez pas d'utiliser un référentiel pour un fichier qui fait partie de votre build. Par exemple, vous
pourrait être tenté d'essayer d'utiliser des référentiels pour mettre tous vos fichiers publics .h dans le même
répertoire, comme ceci :

# makefile de niveau supérieur
référentiel include=module1/include
référentiel include=module2/include
référentiel include=module3/include
référentiel include=module4/include

Ce n'est probablement pas une bonne idée si tout du système .h les fichiers sont eux-mêmes les sorties d'un
programme (par exemple, yacc ou un autre programme qui crache du code source C), car makepp
suppose que les fichiers dans les référentiels ne changent jamais. Si la construction a besoin inclure/xyz.het
module2/include/xyz.h doit en fait être produit par un programme, makepp ne le saura pas
pour exécuter le programme. Il est préférable d'utiliser une technique comme celle-ci pour mettre tous vos .h fichiers
dans un répertoire d'inclusion commun :

# module1/Makeppfile
../include/%.h : inclut/%.h
&cp $(entrée) $(sortie)
# Vous pouvez également (plus efficacement mais problématique sous Windows) effectuer les opérations suivantes :
# &ln -r $(entrée) $(sortie)

Makepp peut toujours essayer de créer des fichiers qui se trouvent dans un référentiel si quelque chose le demande
pour eux directement, mais ça ne les construira pas on nom du répertoire local. Le résultat
cela peut être assez déroutant, car cela peut conduire à ce qu'un lien symbolique de référentiel soit
utilisé alors que sa cible de référentiel est obsolète, mais cette cible peut être mise à jour plus tard
dans la construction. Vous pouvez empêcher que cela se produise en vous assurant que le
référentiel est appelé uniquement via le chemin du référentiel, ou en s'assurant qu'il y a
est également une règle locale pour tous les fichiers de référentiel générés.

Une autre façon d'éviter de recompiler des fichiers identiques dans des répertoires différents est d'utiliser un
cache de construction (voir makepp_build_cache pour plus de détails). Un cache de construction n'a pas le
restriction que le fichier ne peut pas changer.

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