makepp_repositories - Online in de cloud

PROGRAMMA:

NAAM

makepp_repositories -- Hoe repositories te gebruiken voor variantbuilds, voor het onderhouden van een
centrale reeks bronnen en andere dingen

PRODUCTBESCHRIJVING

A bewaarplaats is een map of maphiërarchie buiten de standaardmap die
bevat bestanden die het makefile nodig heeft in de huidige directorystructuur. Makepp kan
automatisch bestanden uit de repository koppelen aan de huidige directorystructuur als dat het geval is
nodig zijn. Repositories bieden vergelijkbare functionaliteit als de variabele "VPATH", maar (in tegenstelling tot
"VPATH" in andere versies van make) hoeft u niets speciaals met uw makefile te doen
om ze aan het werk te krijgen.

Repository's worden opgegeven met de opdrachtregeloptie "-R" of "--repository" of met de
"repository"-instructie in het makefile. Houd er rekening mee dat als u de gewoonte heeft makepp
in verschillende submappen van uw buildboom kunt u gemakkelijk per ongeluk een
bewaarplaats ergens anders. Als bescherming hiertegen, als u gebruik maakt van RootMakepp-bestand, makepp
zal weigeren te starten als het er een vindt boven of onder de plaats waar het zou worden geïmporteerd.

Dit is enigszins vergelijkbaar met de uniebestandssystemen van het besturingssysteem (unionfs...).
huidige map is als de beschrijfbare laag op het hoogste niveau. Alle repository's zijn zoals
onderste alleen-lezen lagen.

Repository's zijn nuttig in verschillende situaties:

· Wanneer u uw object- en uitvoerbare bestanden in een aparte map wilt plaatsen, maar
het makefile is geschreven om ze in dezelfde map als de bronnen te plaatsen.

· Als u hetzelfde programma op twee verschillende manieren wilt bouwen (bijvoorbeeld met twee verschillende
sets compilatieopties, of voor twee verschillende architecturen).

· Wanneer u geen schrijftoegang heeft tot de gehele of een deel van de bronboom.

· Wanneer meerdere ontwikkelaars aan hetzelfde project werken en er een gemeenschappelijke bron is
repository met alle bronnen voor het project. Elke ontwikkelaar kan alleen wijzigingen aanbrengen
de bestanden die hij nodig heeft om in zijn lokale map te wijzigen zonder de andere te beïnvloeden
ontwikkelaars, en makepp haalt automatisch de ongewijzigde bestanden op van de bron
repository.

Makepp's implementatie van repositories vereist geen herschrijven van de build-opdrachten
helemaal niet, in tegenstelling tot (bijvoorbeeld) repositories in cons. Makepp plaatst een symbolische link in het
map waar de opdracht deze verwacht. Zolang het commando niet verwijst naar
absolute mappen, precies hetzelfde shell-commando zal werken met bestanden uit een repository.
Dit betekent dat het niet alleen werkt voor compilatieopdrachten, maar voor elk soort opdracht
kunt bedenken om uw makefile in te voeren.

Makepp heeft een ander soort mechanisme genaamd a bouw cache die een deel van hetzelfde oplost
soort problemen als repositories op een andere manier. Afhankelijk van uw probleem, een build
cache kan nuttiger zijn dan een repository. Zie makepp_build_cache voor informatie over
build-caches en een vergelijking van build-caches en repositories.

Voorbeelden
Repository's kunnen het beste worden uitgelegd aan de hand van verschillende voorbeelden van wat u kunt doen.

Verschillende compilatie opties

Stel dat je een eenvoudig programma hebt met een makefile dat er ongeveer zo uitziet:

CFLAGS = -O2
OBJECTEN = oa bo co
mijn_programma: $(OBJECTEN)
cc $(invoer) -o $(uitvoer)

%.o: %.c
cc $(CFLAGS) -c $(invoer) -o $(uitvoer)

Dit makefile plaatst de bestanden "ao", "bo", "co" en "my_program" in dezelfde map
als de bronbestanden.

Soms wilt u de binaire bestanden in een aparte map plaatsen. Jij bijvoorbeeld
zou uw programma op verschillende architecturen kunnen bouwen, en u wilt het binaire bestand niet
bestanden op de ene architectuur worden vervangen door de binaire bestanden op de andere. Of misschien wel
een tijdelijke wijziging wilt aanbrengen en opnieuw wilt compileren zonder de vorige compilatie te wissen
resultaten. Zonder repositories zou u uw makefile moeten aanpassen om de
voorwerpen elders.

Met een repository hoeft u uw makefile echter helemaal niet aan te raken. Houd rekening met de
volgende reeks opdrachten:

% cd mijn_programma_bron
% makepp # Bouwt met behulp van het bovenstaande make-bestand, en
# objectbestanden gaan naar de map
# mijn_programma_bron.
% cd..
% mkdir binary-debug # Maak een schone map voor het bouwen van de
% cd binary-debug # hetzelfde programma met verschillende opties.
% makepp -R ../mijn_programma_bron CFLAGS=-g
# Nu gaan objecten naar binary-debug.

De eerste makepp-opdracht compileert de bronbestanden met optimalisatie en plaatst de objecten
in de directory "my_program_source", want dat is wat het makefile zou moeten doen
Doen. Nu willen we het programma opnieuw opbouwen, maar we willen de waarde van "CFLAGS" wijzigen in
compileren voor debuggen. We specificeren de nieuwe waarde van "CFLAGS" op de opdrachtregel, en we ook
vertel makepp dat de map "my_program_source" een repository is met behulp van de optie "-R".

Elke keer realiseert makepp zich dat het een bestand nodig heeft dat nog niet in de huidige versie aanwezig is
directory, het kijkt in de repository. In dit geval zoekt het eerst naar het makefile,
die niet bestaat in de submap "binary-debug". Het creëert dus een symbolische link naar
het uit het makefile in "my_program_source", en leest het vervolgens in het makefile. Dan het
merkt op dat het het bestand "ac" nodig heeft om "ao" te bouwen, en dus koppelt het in "ac"
uit de repository. Als "ac" bestanden bevat die zich in "my_program_source" bevinden, dan
ook deze worden automatisch gekoppeld. Opmerking: deze links zijn nuttig voor dingen
zoals debuggen, maar als je ze niet leuk vindt, kan "makeppclean -R" ze verwijderen.

Het uitvoeren van de build-opdracht in "binary-debug" heeft geen invloed op de bestanden in
"mijn_programma_bron". Dus uit dezelfde set bronbestanden heb je nu twee verschillende
kopieën van het programma, één gecompileerd met optimalisatie en één gecompileerd voor foutopsporing. En
dit gebeurde zonder het makefile helemaal aan te raken.

Het voordeel van het gebruik van repositories in plaats van het eenvoudigweg opnieuw compileren en overschrijven van de
originele binaire bestanden is dat we nu onze bugs oplossen en terug willen naar het geoptimaliseerde
versie, hoeven we niet alles opnieuw te compileren. Omdat de originele objectbestanden nog steeds
beschikbaar zijn, en de meeste ervan zijn nog steeds geldig, kunnen we veel tijd besparen bij het opnieuw compileren.
Dit maakt geen groot verschil als het slechts om drie bronbestanden gaat, maar bij a
grotere build die minuten of uren in beslag neemt, de besparing in programmeertijd en
frustratie kan aanzienlijk zijn.

Herbouw een filet Met a minder wijziging naar de compilatie commando's

Makepp haalt niet alleen bronbestanden op uit de repository. Als het objectbestanden in de
repository hoeft niet opnieuw te worden opgebouwd, het zal ze gebruiken. Denk bijvoorbeeld aan een lichte
wijziging aan het bovenstaande makefile:

CLAGS := -O2
A_CFLAGS:= -O6 -funroll-loops

OBJECTEN:= ao bo co

mijn_programma: $(OBJECTEN)
cc $(invoer) -o $(uitvoer)

%.o: %.c
cc $(CFLAGS) -c $(invoer) -o $(uitvoer)

oa: ac
cc $(A_CFLAGS) -c $(invoer) -o $(uitvoer)

Het idee is dat "ao" de tijdkritische code bevat, dus deze wordt gecompileerd met hogere
optimalisatie dan de rest van de objecten. Stel nu dat we willen testen hoe verschillend dat is
de timing is met verschillende compileeropties. Een repository kan hierbij ook helpen:

% cd mijn_programma_bron
% makepp # Bouwt met behulp van het bovenstaande make-bestand, en
# objectbestanden gaan naar de map
# mijn_programma_bron.
% cd..
% mkdir no-unrolling # Maak een schone map voor het bouwen van de
% cd no-unrolling # hetzelfde programma met verschillende opties.
% makepp -R ../mijn_programma_bron A_CFLAGS=-O2
% cd..
% tijd niet uitrollen/mijn_programma # Benchmark de twee versies van het programma.
% tijd mijn_programma_bron/mijn_programma

Makepp gaat verder zoals voorheen, koppelt een kopie van het makefile en onderzoekt vervolgens het object
bestanden. Nu hoeft alleen de module "ao" opnieuw te worden gecompileerd, aangezien de opties voor "bo" en "co"
zijn niet veranderd. Makepp merkt dat het "bo" en "co" uit de repository kan gebruiken, dus
het koppelt deze alleen maar. Het zal echter "ao" opnieuw compileren in de map "no-unrolling".
Zodra de compilatie is voltooid, kunnen de twee verschillende versies van het programma worden gebruikt
gebenchmarkt.

Herbouw Met a minder wijziging naar de (bron)

Stel nu dat we een wijziging willen aanbrengen in "ac" en het programma ervoor en erna willen benchmarken
de verandering. Repositories kunnen weer helpen. Overweeg deze reeks opdrachten:

% mkdir aangepast-a
% cp my_program_source/ac gewijzigd-a
% cd gewijzigd-a
% emacs ac # Breng enkele wijzigingen aan, alleen in deze module.
% makepp -R ../mijn_programma_bron

Hier hebben we een nieuwe map gemaakt die alleen het gewenste bronbestand bevat
bewerken. Makepp haalt nu "ac" uit de submap "modified-a", maar gebruikt de kopieën van
"b" en "c" uit de map "my_program_source". Zonder iets van het binaire bestand te veranderen
bestanden in "my_program_source", hebben we een aparte kopie gemaakt van het programma dat
bevat onze wijzigingen in "ac". Als er andere ontwikkelaars zijn die de bronnen gebruiken in
"my_program_source", zullen ze niet worden beïnvloed door onze wijzigingen.

Repositories kunnen dus worden gebruikt als een snelle manier om varianten van een programma te bouwen, zonder dat dit nodig is
het toevoegen van ingewikkelde voorwaarden aan het makefile. Geen van de bestanden in het origineel
directory zijn gewijzigd; ze worden gebruikt als dat nodig is.

gebruik a directory hiërarchie

Een repository is eigenlijk niet zomaar een enkele directory, het is een hele directoryhiërarchie.
Stel dat je gebruikt /onze/bibliotheek als bewaarplaats. Nu /onze/bibliotheek kan er heel veel bevatten
submappen, bijv. /onze/bibliotheek/gui en /onze/bibliotheek/netwerk. Overweeg dit commando:

% makepp -R /onze/bibliotheek

Alle opdrachten in de makefile die verwijzen naar bestanden in de directory ./netwerk zal eigenlijk
bestanden ophalen /onze/bibliotheek/netwerk, en op dezelfde manier voor ./gui. Automatisch maken
maakt alle mappen aan die in de repository bestaan, maar niet in de huidige map.

Koppelen naar elke plaats in de filet system

Alle bovenstaande voorbeelden laten zien dat bestanden uit een repository zijn gekoppeld aan de huidige
map of de submappen ervan, maar je kunt makepp ze feitelijk naar elke plek laten linken
in het bestandssysteem waartoe u schrijftoegang heeft. Dit gebeurt door te specificeren
"-R nieuwe locatie=oude locatie".

Soms is het bijvoorbeeld een beetje vervelend om het volgende te typen:

mkdir alternatieve build
cd alternatieve build
makepp -R ..

Je kunt het allemaal doen met één commando, zoals dit:

makepp -R alternatief-build=. -F alternatieve build

"-F" of "-makeppfile" wijzigt naar die map voordat het makefile wordt geladen. Je moet
specificeer "-R" vóór "-F". Merk op dat dit voorbeeld de nieuwe build-boom in de
opslagplaats. Dat werkt niet als je een RootMakepp-bestand omdat makepp beschermt
tegen geneste bomen. Het is ook geen goed idee als je het gebruikt **, want als je ooit bouwt
in de repository vindt het ook bewerkte en gegenereerde bestanden in deze subboom.

Het toewijzen van een andere locatie in het bestandssysteem kan ook handig zijn voor ingewikkelder bestanden
builds, waar er verschillende bibliotheeksubmappen zijn. Hier is bijvoorbeeld een opdracht I
heb gebruikt om varianten van een van mijn programma's te bouwen:

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

Deze opdracht laadt bestanden uit vier verschillende repository's en vervolgens cd's naar de
./test-build/seescape directory en voert daar het makefile uit. Bestanden in de
directorystructuur beginnend met /src/seescape zijn gekoppeld ./test-build/seescape. in
met andere woorden, makepp zal het bestand tijdelijk koppelen /src/seescape/gui/image_canvas.cxx naar
./test-build/seescape/gui/image_canvas.cxx wanneer het nodig is. Deze opdracht werkt zelfs
als de map "test-build" nog niet bestaat; makepp zal het voor u maken. (Maar jij
moet de "-R"-opties opgeven vóór de "-F"-optie op de opdrachtregel.)

meervoudig gelijkwaardig repositories

Stel dat uw project wordt beheerd door verschillende redelijk autonome groepen. Je zou er een kunnen hebben
complete repository met alle bronnen zoals ze in productie zijn of op zijn minst
succesvol getest. Elke groep kan een grotendeels lege repository hebben met (een deel van) de
dezelfde structuur, met daarin de bestanden die groepsleden hebben ontwikkeld.

In de huidige mappen van ontwikkelaars staan ​​de bestanden waar ze nog aan werken. De groep
repository zal de eerste zijn die wordt gegeven en de productierepository de laatste, dus dat
het levert de bestanden op die niet in de groepsrepository voorkomen:

$ makepp -R/pad/naar/groep/repository -R/pad/naar/productie/repository

Omdat dit waarschijnlijk vrij statisch is voor die map, wil je misschien een bestand plaatsen
.makepprc in de root met de volgende inhoud:

-R/pad/naar/groep/repository -R/pad/naar/productie/repository

Of, ervan uitgaande dat het een vast pad heeft, zou je in je makefile kunnen schrijven:

repository /pad/naar/productie/repository

en omdat opties worden gezien voordat makefiles worden gelezen, kunt u vervolgens gewoon

$ makepp -R/pad/naar/groep/repository

Vindplaatsen as vast deel of jouw bouw system

Als je weet dat je altijd een bepaalde repository gebruikt, kun je de "repository" of "vpath" gebruiken
uitspraken in uw makefile.

Voorbehoud Met repositories
. de links krijgen in de weg

Voor het vinden van uw weg in uw bestandshiërarchie en voor het toestaan ​​dat de debugger het
bronnen is het handig om de links te gebruiken tijdens het bouwen. Maar als je een
bestand of synchroniseer het opnieuw met uw versiebeheer, de links kunnen in de weg zitten. Dat is
omdat het systeem de link passeert en naar het bestand in de repository schrijft. Tenzij
het is je persoonlijke opslagplaats die alleen wordt gebruikt om dingen uit elkaar te houden, dat is misschien niet wat jij bent
willen.

Als beveiliging tegen het onbedoeld overschrijven van openbare bestanden wordt voorgesteld om de
bronnen in de repository zijn onschrijfbaar. Het is misschien zelfs niet genoeg om de schrijfwijze te verwijderen
bit, omdat het een versiecontrolesysteem is dat erop aandringt dat u de bestanden vergrendelt voor bewerking
kan dat ook doen, maar maak het bestand tijdelijk beschrijfbaar terwijl u het opnieuw synchroniseert. Als dat zo is
In jouw geval zou de repository eigenlijk van een andere gebruiker moeten zijn.

Er zijn een paar tactieken om dit te overwinnen:

· Bewaar de bronnen die u bewerkt in een repository, gescheiden van uw buildboom. Wanneer dan ook
je plaatst hierin een bestand dat eerder uit een andere repository is opgehaald
bewerkingsrepository zal makepp het opmerken en het daar ophalen, op voorwaarde dat het de
eerste opslagplaats die u opgeeft.

· Vergeet niet elk bestand te verwijderen voordat u een kopie maakt om te schrijven. Als u de
beveiligingssuggestie hierboven, als u dit vergeet te doen, krijgt u een foutmelding wanneer
schrijven. Om u te helpen zal de volgende functie "ontkoppelen" één link vervangen door een kopie
van het gekoppelde bestand. De eerste variant is voor alle soorten Bournish Shells, de tweede
één voor csh (of op zijn minst tcsh):

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

· Als u denkt dat u ze niet nodig heeft, kunt u ze allemaal verwijderen, wanneer u maar wilt, bijvoorbeeld
na elke makepp-run, mogelijk op de achtergrond (korte of lange vorm):

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

Niet bouw in a bewaarplaats gedurende .

Het is de bedoeling dat een repository alleen-lezen is wanneer deze als repository wordt gebruikt. Makepp zal het doen
niet goed werken als u tijdens een build bestanden in uw repository wijzigt.
Nachtelijke builds zijn wellicht geschikt voor u, als niemand anders de repository op dat moment gebruikt. Voor
het start de build, makepp krijgt een lijst met alle bestanden die in de repository bestaan, en
werkt de lijst nooit bij, behalve de bestanden die het verwacht te verschijnen.

Als je een repository nodig hebt die verandert terwijl je bouwt, kun je makepp's overwegen
build cache-mechanisme (zie makepp_build_cache). Als alternatief kunt u een 'arme man's' gebruiken
repository": u kunt expliciete regels in uw makefile plaatsen om zachte links te maken, zoals
deze:

%.c: $(directory_I_wish_was_a_repository)/%.c
&ln -fs $(invoer) $(uitvoer)

Dit werkt alleen voor bronbestanden; je kunt dit niet gemakkelijk gebruiken om een ​​bestand te koppelen als dat het geval is
al gebouwd in de repository, maar bouw het hier als het nog niet gebouwd is, aangezien het daar is
mag slechts één manier zijn om een ​​bestand op te bouwen.

Te gebruiken Slechts relatief bestandsnamen

Repositories werken volledig transparant if de maakbestanden . Slechts relatief bestandsnamen.
In het bovenstaande voorbeeld is het geen probleem als het makefile in /src/seescape verwijst naar ../HLib, Maar de
bovenstaande opdracht werkt niet zoals verwacht als deze verwijst naar /src/HLib. Als je moet gebruiken
absolute bestandsnamen, kunt u deze in make-variabelen plaatsen en ze vervolgens overschrijven in de
opdrachtregel, zoals deze:

% 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/externe_bibliotheken/qwt QWT=/home/holt/test-build/qwt \
-F testbuild/seescape

Het bovenstaande werkt zolang de map "HLib" in alle bestanden wordt aangeduid als "$(HLIB)".
maakbestanden. Houd er rekening mee dat u absolute paden voor de mappen moet opgeven, omdat
makepp cd's naar "test-build/seescape" voordat u het makefile leest. Dit leidt tot lange en
ingewikkelde maakopdrachten; gebruik waar mogelijk relatieve paden.

Makepp Dan moet je om te weten wat over ons allen afhankelijkheden

Repository's zullen niet werken als er verborgen afhankelijkheden zijn die makepp niet kent
over. (In feite is het uitvoeren van een build met behulp van repository's een manier om te controleren op vergeten bestanden
afhankelijkheden. Maar combineer het alleen voor deze controle niet met een build-cache
door daar iets op te halen, in plaats van het te bouwen, kan een vergeten afhankelijkheid verborgen blijven.)
Soms kunnen deze afhankelijkheden tamelijk subtiel zijn. Bijvoorbeeld de libtool bevel zal
maak niet alleen ".lo"- en ".la"-bestanden zoals vermeld op de opdrachtregel, maar dat kan ook
maak een submap met de naam ".libs" die de daadwerkelijke objectbestanden bevat. Voorkomen
build-fouten, makepp weigert een ".la"-bestand uit een repository te linken. Hopelijk binnen
de toekomstige libtool zal beter ondersteund worden.

Veel verborgen afhankelijkheden met betrekking tot compilatie worden opgevangen door de opdrachtregelscanner.
Als uw compiler de gebruikelijke Unix-compilatievlaggen gebruikt (bijvoorbeeld "-I", "-D", enz.), dan
makepp zal meestal uitzoeken waar al uw include-bestanden zich bevinden. Misschien moet je dat wel zijn
wees voorzichtig als je scripts van eigen bodem hebt die bestanden maken die makepp niet kent
over. Voor correcte builds is het van cruciaal belang dat u een lijst maakt allen doelstellingen en afhankelijkheden
(of bepaal ze automatisch door te scannen).

Putting absoluut bestandsnamen in programma's

Repository's zullen ook niet werken als een van de gebouwde bestanden absolute bestandsnamen bevat
(bijvoorbeeld als een van uw build-opdrachten een absolute bestandsnaam schrijft). Bijvoorbeeld,
het blijkt dat de ".la"-bestanden geproduceerd zijn door libtool deze eigenschap hebben. (Als je kijkt
Als u de inhoud van het ".la"-bestand bekijkt, ziet u dat de afhankelijkheidslijst absoluut bevat
bestandsnamen.) Om dit specifieke probleem op te lossen, zal makepp geen ".la"-bestanden koppelen
vanuit een opslagplaats; het zal aandringen op de wederopbouw ervan.

vermijden Koppeling in onnodig directories

Repository's kunnen traag zijn bij het opstarten en veel geheugen gebruiken als er veel zijn
onnodige bestanden in de repository. Als u bijvoorbeeld een automatische HTML
documentatiegenerator die duizenden ".html"-bestanden van uw broncode maakt
wil ze misschien niet in een submap plaatsen van een map die als repository wordt gebruikt.
Het is beter om ze volledig in een andere directorystructuur te plaatsen, dus de repository
mechanisme laadt niet in hun naam.

Te Veel Bestanden

Het nadeel van repositories is dat er symbolische links zijn, die het repositorymechanisme vormen
gebruikt, zijn individuele bestanden (hoewel ze bijna geen schijfruimte in beslag nemen). Dit is anders dan in het echt
koppelingen, maar deze kunnen de grenzen van het bestandssysteem niet overschrijden. In extreme gevallen kan de aanwezigheid van
zeer veel symbolische links kunnen leiden tot uitputting van het aantal voorziene bestanden (zogenaamde
inodes), ook al is er nog voldoende ruimte over. In dit geval heeft de systeembeheerder dit nodig
om het bestandssysteem af te stemmen.

Dwingend bewaarplaats kopieën
Als u lokaal wijzigingen in een bestand aanbrengt, zal makepp dit doorgaans realiseren
compileer het bestand opnieuw met behulp van de lokale kopie in plaats van de repositorykopie.

Als u een repository gebruikt om een ​​centrale codebasis te onderhouden en u ontwikkelaars heeft
werken aan lokale kopieën die alleen de bestanden bevatten die ze hebben gewijzigd, een probleem daarbij
naar voren komt is: wat als een ontwikkelaar een bestand uit zijn lokale build wil verwijderen, maar het
repository bevat het nog steeds? Als de ontwikkelaar de lokale kopie verwijdert, zal makepp dat doen
plaats met plezier de kopie uit de repository en de build zal doorgaan alsof het bestand is
bestonden.

Eén techniek (helaas niet voor gebruiker root) voor dit probleem is het maken van het gewenste bestand
niet op te nemen in het bouwproces onleesbaar, zoals dit:

chmod a-rw-bestand dat moet worden uitgesloten

Dit voorkomt dat makepp het uit de repository opneemt. Makepp omvat ook
speciale code zodat onleesbare bestanden niet overeenkomen met jokertekens of patroonregels.

Op dezelfde manier kunt u, om te voorkomen dat makepp een hele submap opneemt, een local
directory met dezelfde naam, maar die niet beschrijfbaar is. Als je wilt dat makepp het
map volledig, en maak hem dan ook onleesbaar. (Alleen-lezen mappen worden doorzocht, maar
doelen daarin zijn meestal niet gebouwd.)

De andere manier om dit te doen is makepp aanroepen met een of meer uitsluitingsopties:

mpp -R /pad/naar/rep --dont-read=/pad/naar/rep/bestand-dat-uitgesloten moet worden

Niet . repositories For bestanden welke wel verandering!
Probeer geen repository te gebruiken voor een bestand dat deel uitmaakt van uw build. Jij bijvoorbeeld
zou in de verleiding kunnen komen om repositories te gebruiken om al uw openbare .h-bestanden in dezelfde te plaatsen
map, zoals deze:

# makefile op het hoogste niveau
repository include=module1/include
repository include=module2/include
repository include=module3/include
repository include=module4/include

Dit is waarschijnlijk geen goed idee als elke van de .h bestanden zijn zelf uitvoer van a
programma (bijvoorbeeld yacc of een ander programma dat C-broncode uitspuugt), omdat makepp
gaat ervan uit dat bestanden in repositories nooit veranderen. Als de bouw nodig heeft include/xyz.h en
module2/include/xyz.h moet eigenlijk door een of ander programma worden geproduceerd, makepp weet het niet
om het programma uit te voeren. Het is beter om een ​​techniek als deze te gebruiken om al je .h bestanden
in een gemeenschappelijke include-directory:

# module1/Makeppbestand
../insluiten/%.h : omvatten/%.h
&cp $(invoer) $(uitvoer)
# U kunt ook (efficiënter maar problematisch op Windows) het volgende doen:
# &ln -r $(invoer) $(uitvoer)

Makepp kan nog steeds proberen bestanden te bouwen die zich toevallig in een repository bevinden als er iets om wordt gevraagd
rechtstreeks voor hen, maar het zal ze niet bouwen on namens van de lokale map. Het resultaat
hiervan kan behoorlijk verwarrend zijn, omdat het ertoe kan leiden dat er een symbolische link in de repository ontstaat
gebruikt terwijl het repositorydoel verouderd is, maar dat doel kan later worden bijgewerkt
in de bouw. U kunt dit voorkomen door ervoor te zorgen dat de
repository wordt verwezen Slechts via het repositorypad, of door ervoor te zorgen dat dat daar is
is ook een lokale regel voor alle gegenereerde repositorybestanden.

Een andere manier om te voorkomen dat identieke bestanden in verschillende mappen opnieuw worden gecompileerd, is door een
build cache (zie makepp_build_cache voor details). Een build-cache heeft niet de
beperking dat het bestand niet mag veranderen.

Gebruik makepp_repositories online met behulp van onworks.net-services