makepp_repositories - Online în cloud

PROGRAM:

NUME

makepp_repositories -- Cum să utilizați depozitele pentru variante de construcție, pentru întreținerea unui
set central de surse și alte lucruri

DESCRIERE

A depozit este un director sau ierarhie de director în afara directorului implicit care
conține fișiere de care makefile-ul are nevoie în arborele curent de directoare. Makepp poate
leagă automat fișierele din depozit în arborele de directoare curent, dacă acestea sunt
Necesar. Arhivele oferă funcționalități similare cu variabila „VPATH”, dar (spre deosebire de
„VPATH” în alte versiuni de make) nu trebuie să faceți nimic special pentru makefile
pentru a-i pune la muncă.

Arhivele sunt specificate cu opțiunea de linie de comandă „-R” sau „--repository” sau cu
declarația „repository” în makefile. Rețineți că, dacă aveți un obicei de a suna makepp
în diferite subdirectoare ale arborelui de construcție, este ușor să reimportați accidental a
depozit în altă parte. Ca o garanție împotriva acestui lucru, dacă utilizați RootMakeppfile, makepp
va refuza să înceapă dacă găsește unul deasupra sau mai jos de unde ar fi importat.

Acest lucru este oarecum comparabil cu sistemele de fișiere union ale sistemului de operare (unionfs...).
directorul curent este ca cel mai înalt nivel care poate fi scris. Toate depozitele sunt ca
straturi inferioare numai pentru citire.

Arhivele sunt utile în mai multe situații diferite:

· Când doriți să plasați obiectul și fișierele executabile într-un director separat, dar
makefile-ul este scris pentru a le plasa în același director cu sursele.

· Când doriți să construiți același program în două moduri diferite (de exemplu, cu două moduri diferite
seturi de opțiuni de compilare sau pentru două arhitecturi diferite).

· Când nu aveți acces de scriere la tot sau la o parte din arborele sursă.

· Când mai mulți dezvoltatori lucrează la același proiect și există o sursă comună
depozit care conține toate sursele pentru proiect. Fiecare dezvoltator poate modifica numai
fișierele pe care trebuie să le schimbe în directorul său local fără a-l afecta pe celălalt
dezvoltatorii, iar makepp va prelua automat fișierele nemodificate de la sursă
repertoriu.

Implementarea de către Makepp a depozitelor nu necesită rescrierea comenzilor de compilare
deloc, spre deosebire de (de exemplu) depozitele din cons. Makepp pune o legătură simbolică în
directorul în care comanda o așteaptă. Atâta timp cât comanda nu se referă la
directoare absolute, exact aceeași comandă shell va funcționa cu fișierele dintr-un depozit.
Aceasta înseamnă că funcționează nu numai pentru comenzi de compilare, ci și pentru orice fel de comandă
se poate gândi să pun în makefile.

Makepp are un alt tip de mecanism numit a construi cache care rezolvă unele dintre ele
feluri de probleme ca depozite într-un mod diferit. În funcție de problema ta, o construcție
memoria cache poate fi mai utilă decât un depozit. Consultați makepp_build_cache pentru informații despre
build cache-uri și o comparație a build cache-urile și depozitele.

Exemple
Arhivele sunt explicate cel mai bine prin câteva exemple de ceea ce puteți face.

Diferit compilare Opțiuni

Să presupunem că aveți un program simplu cu un makefile care arată cam așa:

CFLAGS = -O2
OBIECTE = ao bo co
my_program: $(OBIECTE)
cc $(intrări) -o $(ieșire)

%.o: %.c
cc $(CFLAGS) -c $(intrare) -o $(ieșire)

Acest makefile plasează fișierele „ao”, „bo”, „co” și „my_program” în același director
ca fișiere sursă.

Uneori doriți să plasați fișierele binare într-un director separat. De exemplu, tu
s-ar putea să vă construiți programul pe mai multe arhitecturi diferite și nu doriți binarul
fișierele de pe o arhitectură pentru a fi înlocuite cu fișierele binare de pe cealaltă. Sau ai putea
doriți să faceți o modificare temporară și să recompilați fără a șterge compilația anterioară
rezultate. Fără depozite, ar trebui să vă modificați makefile pentru a plasa fișierul
obiecte în altă parte.

Cu un depozit, totuși, nu trebuie să atingeți deloc fișierul makefile. Considera
următoarea secvență de comenzi:

% cd my_program_source
% makepp # Construiește folosind fișierul make de mai sus și
# fișiere obiect intră în director
# my_program_source.
% cd ..
% mkdir binary-debug # Faceți un director curat pentru construirea
% cd binary-debug # același program cu opțiuni diferite.
% makepp -R ../my_program_source CFLAGS=-g
# Acum obiectele intră în binary-debug.

Prima comandă makepp compilează fișierele sursă cu optimizare și pune obiectele
în directorul „my_program_source”, pentru că asta ar trebui să facă fișierul make
do. Acum vrem să reconstruim programul, dar vrem să schimbăm valoarea „CFLAGS” în
compilați pentru depanare. Specificăm noua valoare a „CFLAGS” pe linia de comandă și, de asemenea, noi
spune-i lui makepp că directorul „my_program_source” este un depozit folosind opțiunea „-R”.

De fiecare dată când makepp realizează că are nevoie de un fișier pe care nu îl are deja în curent
director, se uită în depozit. În acest caz, caută mai întâi fișierul make,
care nu există în subdirectorul „binary-debug”. Deci creează o legătură simbolică către
este din fișierul make din „my_program_source” și apoi citește în makefile. Atunci acesta
observă că are nevoie de fișierul „ac” pentru a construi „ao”, și astfel se leagă în „ac”
din depozit. Dacă „ac” include fișiere conținute în „my_program_source”, atunci
și acestea vor fi conectate automat. Notă: acele link-uri sunt utile pentru lucruri
ca depanarea, dar dacă nu vă plac, „makeppclean -R” le poate elimina.

Rularea comenzii de compilare în „binary-debug” nu va atinge niciunul dintre fișierele din
„sursa_programului_meu”. Astfel, din același set de fișiere sursă, acum aveți două diferite
copii ale programului, una compilată cu optimizare și una compilată pentru depanare. Și
acest lucru s-a întâmplat fără a atinge deloc fișierul make.

Avantajul utilizării depozitelor în loc să recompileze și să suprascrie pur și simplu fișierul
binarele originale este că acum, dacă ne reparăm erorile și vrem să revenim la optimizat
versiune, nu trebuie să recompilăm totul. Deoarece fișierele obiect originale sunt încă
în jur, iar cele mai multe dintre ele sunt încă valabile, putem economisi mult timp la recompilare.
Acest lucru nu face o mare diferență atunci când sunt implicate doar trei fișiere sursă, dar pentru a
o construcție mai mare care durează câteva minute sau ore pentru a fi finalizată, economiile de timp ale programatorului și
frustrarea poate fi semnificativă.

Reconstrucţie unu fişier implementate cu a minor modificare la il compilare comenzi

Makepp nu preia numai fișierele sursă din depozit. Dacă obiectul fișiere în fișierul
depozitul nu are nevoie de reconstrucție, le va folosi. De exemplu, luați în considerare o ușoară
modificare la makefile de mai sus:

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

OBIECTE := ao bo co

my_program: $(OBIECTE)
cc $(intrări) -o $(ieșire)

%.o: %.c
cc $(CFLAGS) -c $(intrare) -o $(ieșire)

ao: ac
cc $(A_CFLAGS) -c $(intrare) -o $(ieșire)

Ideea este că „ao” conține codul critic în timp, deci este compilat cu mai mare
optimizare decât restul obiectelor. Acum să presupunem că vrem să testăm cât de diferit
sincronizarea este cu diferite opțiuni de compilare. Un depozit poate ajuta și cu asta:

% cd my_program_source
% makepp # Construiește folosind fișierul make de mai sus și
# fișiere obiect intră în director
# my_program_source.
% cd ..
% mkdir no-unrolling # Faceți un director curat pentru construirea
% cd no-unrolling # același program cu opțiuni diferite.
% makepp -R ../my_program_source A_CFLAGS=-O2
% cd ..
% timp no-unrolling/my_program # Comparați cele două versiuni ale programului.
% timp sursa_programului_meu/programul_meu

Makepp procedează ca înainte, conectând o copie a fișierului make și apoi examinând obiectul
fișiere. Acum doar modulul „ao” trebuie recompilat, deoarece opțiunile pentru „bo” și „co”
nu s-au schimbat. Makepp observă că poate folosi „bo” și „co” din depozit, deci
le leagă doar pe acelea inch. Cu toate acestea, va recompila „ao” în directorul „no-unrolling”.
Odată ce compilarea este terminată, cele două versiuni diferite ale programului pot fi
etalonat.

Reconstrucţie implementate cu a minor modificare la il sursă

Acum să presupunem că vrem să facem o schimbare la „ac” și să facem benchmark programul înainte și după
schimbarea. Arhivele pot ajuta din nou. Luați în considerare această secvență de comenzi:

% mkdir modificat-a
% cp sursa_programului_meu/ac modificat-a
% cd modificat-a
% emacs ac # Faceți câteva modificări doar la acest modul.
% makepp -R ../sursa_programului_meu

Aici am creat un nou director care conține doar un singur fișier sursă pe care vrem să îl facem
modifica. Makepp ia acum „ac” din subdirectorul „modified-a”, dar folosește copiile lui
„b” și „c” din directorul „my_program_source”. Fără a schimba nimic din binar
fișierele din „my_program_source”, am creat o copie separată a programului care
încorporează modificările noastre la „ac”. Dacă există alți dezvoltatori care folosesc sursele în
„my_program_source”, acestea nu vor fi afectate de modificările noastre.

Arhivele pot fi astfel folosite ca o modalitate rapidă de a construi variante ale unui program, fără
adăugând condiții complicate la makefile. Niciunul dintre fișiere în original
directorul sunt modificati; sunt folosite la nevoie.

Utilizarea a director ierarhie

Un depozit nu este de fapt doar un singur director, este o întreagă ierarhie de directoare.
Să presupunem că folosiți /noastre/biblioteca ca depozit. Acum /noastre/biblioteca poate conține multe
subdirectoare, de exemplu, /noastre/biblioteca/gui și /noastre/biblioteca/rețeaua. Luați în considerare această comandă:

% makepp -R /nostru/biblioteca

Orice comenzi din makefile care se referă la fișiere din director ./reţea de fapt
obține fișiere de la /noastre/biblioteca/rețeaua, și în mod similar pentru ./gui. Makepp automat
creează orice directoare care există în depozit, dar nu în directorul curent.

Legarea la Orice loc in il fişier sistem

Toate exemplele de mai sus arată că fișierele dintr-un depozit sunt legate la curent
directorul sau subdirectoarele acestuia, dar de fapt puteți solicita makepp să le conecteze în orice loc
în sistemul de fișiere la care aveți acces de scriere. Acest lucru se face prin specificare
„-R new-location=veche-locație”.

De exemplu, uneori este puțin plictisitor să tastați următoarele:

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

Puteți face totul cu o singură comandă, astfel:

makepp -R alternate-build=. -F alternativ-construire

„-F” sau „-makeppfile” se modifică în acel director înainte de a încărca makefile. Trebuie să vă
specificați „-R” înainte de „-F”. Rețineți că acest exemplu pune noul arbore de construcție în interiorul
repertoriu. Asta nu va funcționa dacă utilizați un RootMakeppfile pentru că makepp garantează
împotriva copacilor cuibărit. De asemenea, nu este o idee bună dacă utilizați **, pentru că dacă vei construi vreodată
în depozit va găsi, de asemenea, fișiere editate și generate în acest subarboresc.

Atribuirea unei locații diferite în sistemul de fișiere poate fi utilă și pentru mai complicate
build-uri, unde există mai multe subdirectoare de bibliotecă. De exemplu, iată o comandă I
am folosit pentru a construi variante ale unuia dintre programele mele:

% 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

Această comandă încarcă fișiere din patru depozite diferite și apoi CD-uri în
./test-build/seescape director și execută makefile-ul acolo. Fișierele conținute în
arborele de directoare care începe cu /src/seescape sunt legate în ./test-build/seescape. În
cu alte cuvinte, makepp va lega temporar fișierul /src/seescape/gui/image_canvas.cxx la
./test-build/seescape/gui/image_canvas.cxx când este nevoie. Această comandă va funcționa chiar
dacă directorul „test-build” nu există încă; makepp îl va crea pentru tine. (Dar tu
trebuie să specifice opțiunile „-R” înainte de opțiunea „-F” pe linia de comandă.)

Multiplu echivalent arhive

Să presupunem că proiectul tău este întreținut de mai multe grupuri destul de autonome. Ai putea avea unul
depozit complet cu toate sursele așa cum sunt în producție sau cel puțin
testat cu succes. Fiecare grup poate avea un depozit în mare parte gol cu ​​(o parte din) fișierul
aceeași structură, care conține fișierele pe care membrii grupului au terminat de dezvoltat.

Directorele actuale ale dezvoltatorilor vor avea fișierele la care încă lucrează. Grupul
depozitul va fi primul dat și depozitul de producție ultimul, astfel încât
furnizează fișierele care nu se găsesc în depozitul de grup:

$ makepp -R/cale/către/grup/depozitiv -R/cale/către/producție/depozit

Deoarece acest lucru este probabil destul de static pentru acel director, poate doriți să puneți un fișier
.makepprc la rădăcina sa cu următorul conținut:

-R/cale/către/grup/depozitiv -R/cale/către/producție/depozitiv

Sau, presupunând că are o cale fixă, puteți scrie în fișierul dvs. make:

depozit /cale/la/producție/repozitiv

și, deoarece opțiunile sunt văzute înainte ca fișierele make să fie citite, apoi puteți apela doar

$ makepp -R/cale/la/grup/repozitiv

Repozitorii as fixată parte of ta construi sistem

Dacă știi că folosești întotdeauna un depozit, poți folosi „repository” sau „vpath”
declarații din makefile.

Rezerve implementate cu arhive
Cand il Link-uri obține in il mod

Pentru a vă găsi calea în ierarhia fișierelor și pentru a permite depanatorului să găsească fișierul
surse este util să folosiți legăturile în timpul construirii. Dar când doriți să editați un
fișier sau resincronizați-l cu controlul versiunii dvs., legăturile pot sta în cale. Acesta este
deoarece sistemul traversează legătura și scrie în fișierul din depozit. Dacă nu
este depozitul dvs. personal folosit doar pentru a menține lucrurile deoparte, poate că nu este ceea ce dvs
vrei.

Ca o garanție împotriva suprascrierii accidentale a fișierelor publice, se recomandă să faceți
sursele din depozit inscriptibile. S-ar putea chiar să nu fie suficient să eliminați scrierea
bit, deoarece un sistem de control al versiunilor care insistă asupra blocării fișierelor pentru editare
ar putea, de asemenea, să facă asta, dar temporar să facă fișierul inscriptibil în timp ce îl resincronizează. Dacă asta este
În cazul dvs., depozitul ar trebui să aparțină de fapt unui alt utilizator.

Există câteva tactici pentru a depăși acest lucru:

· Păstrați sursele pe care le editați într-un depozit, separat de arborele dvs. de compilare. Oricând
ați pus un fișier, care a fost preluat anterior dintr-un alt depozit, în acesta
depozit de editare, makepp îl va observa și îl va prelua de acolo, cu condiția să fie
primul depozit pe care îl specificați.

· Nu uitați să ștergeți orice fișier înainte de a crea o copie pentru scris. Dacă urmați
Sugestia de salvgardare de mai sus, dacă uitați să faceți acest lucru, se va afișa un mesaj de eroare când
scris. Pentru a vă ajuta, următoarea funcție „delink” va înlocui un link cu o copie
a fișierului legat. Prima variantă este pentru toate tipurile de Bournish Shells, a doua
unul pentru csh (sau cel puțin tcsh):

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

· Dacă simțiți că nu aveți nevoie de ele, le puteți șterge pe toate, oricând doriți, de ex
după fiecare rulare makepp, eventual pe fundal (fie formă scurtă sau lungă):

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

nu face construi in a depozit în timpul utilizare

Un depozit este menit să fie doar pentru citire în timp ce este utilizat ca depozit. Makepp va
nu funcționează corect dacă modificați fișierele din depozit în timpul unei build.
Compilările nocturne pot fi ok pentru dvs., dacă nimeni altcineva nu folosește depozitul în acel moment. Inainte de
pornește construirea, makepp primește o listă cu toate fișierele care există în depozit și
nu își actualizează niciodată lista, cu excepția fișierelor pe care se așteaptă să apară.

Dacă aveți nevoie de un depozit care se schimbă pe măsură ce construiți, poate doriți să luați în considerare makepp's
build cache-mecanism (vezi makepp_build_cache). Alternativ, puteți folosi un „sărac
depozit": puteți pune reguli explicite în fișierul dvs. make pentru a crea link-uri soft, cum ar fi
acest:

%.c : $(directory_I_wish_was_a_repository)/%.c
&ln -fs $(intrare) $(ieșire)

Acest lucru funcționează numai pentru fișierele sursă; nu puteți utiliza cu ușurință acest lucru pentru a lega un fișier dacă este
deja construit în depozit, dar construiți-l aici dacă nu este deja construit, de acolo
poate fi doar o modalitate de a construi un fișier.

Utilizare relativ nume de fișiere

Arhivele funcționează complet transparent if il makefiles utilizare relativ nume de fișiere.
În exemplul de mai sus, este ok dacă makefile în /src/seescape se referă la ../HLib, Dar
comanda de mai sus nu va funcționa așa cum era de așteptat dacă se referă la /src/HLib. Dacă trebuie să utilizați
nume absolute de fișiere, le puteți pune în variabilele make și apoi le puteți suprascrie pe
linie de comandă, astfel:

% 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

Cele de mai sus vor funcționa atâta timp cât directorul „HLib” este denumit „$(HLIB)” în toate
makefiles. Rețineți că trebuie să specificați căi absolute pentru directoare, deoarece
cd-urile makepp la „test-build/seescape” înainte de a citi makefile. Acest lucru duce la lung și
comenzi complicate de efectuare; utilizați căi relative atunci când este posibil.

Makepp trebuie să: ști despre toate dependențe

Arhivele nu vor funcționa dacă există dependențe ascunse pe care makepp nu le cunoaște
despre. (De fapt, a face o construcție folosind depozite, este o modalitate de a verifica dacă sunt uitate
dependențe. Dar, doar pentru această verificare, nu o combinați cu un cache de compilare, deoarece
a aduce ceva acolo, în loc să-l construiască, ar putea ascunde o dependență uitată.)
Uneori, aceste dependențe pot fi destul de subtile. De exemplu, cel libtool comanda va
nu numai că creați fișiere „.lo” și „.la” așa cum sunt listate pe linia de comandă, dar poate și
creați un subdirector numit „.libs” care conține fișierele obiect reale. A preveni
build greșeli, makepp refuză să conecteze într-un fișier „.la” dintr-un depozit. Sper că în
viitorul libtool va fi mai bine suportat.

Multe dependențe ascunse legate de compilare sunt surprinse de scanerul din linia de comandă.
Dacă compilatorul dumneavoastră folosește steagurile de compilare Unix comune (de exemplu, „-I”, „-D”, etc.), atunci
makepp își va da seama unde sunt toate fișierele incluse. Poate că trebuie să fii
Atenție dacă aveți scripturi de origine care creează fișiere pe care makepp nu le cunoaște
despre. Pentru construirea corectă, este extrem de important să enumerați toate ținte și dependențe
(sau determinați-le automat prin scanare).

Punând absolut nume de fișiere în programe

De asemenea, arhivele nu vor funcționa dacă oricare dintre fișierele construite conține nume absolute de fișiere
ele (de exemplu, dacă oricare dintre comenzile dvs. de compilare scrieți un nume de fișier absolut). De exemplu,
rezultă că fișierele „.la” produse de libtool au această proprietate. (Dacă te uiți la
conținutul fișierului „.la” veți vedea că lista de dependențe conține absolut
nume de fișiere.) Pentru a rezolva această problemă specială, makepp nu va lega fișierele „.la”.
dintr-un depozit; va insista asupra reconstruirii lor.

Evita legarea in inutil directoare

Arhivele pot fi lente la pornire și pot folosi multă memorie dacă există multă
fișiere inutile din depozit. De exemplu, dacă utilizați un HTML automat
generator de documentație care face mii de fișiere „.html” din codul sursă, tu
s-ar putea să nu doriți să le puneți într-un subdirector al unui director care este folosit ca depozit.
Este mai bine să le puneți într-un arbore de directoare complet diferit, deci depozitul
mecanismul nu se va încărca în numele lor.

De asemenea Multe Fişiere

Dezavantajul depozitelor este că legăturile simbolice, care mecanismul de depozit
utilizări, sunt fișiere individuale (deși nu folosesc aproape deloc spațiu pe disc). Acest lucru este diferit de real
link-uri, dar acestea nu pot depăși granițele sistemului de fișiere. În cazuri extreme prezența
foarte multe legături simbolice pot duce la epuizarea numărului de fișiere prevăzute (așa-numitele
inode), chiar dacă mai rămâne mult spațiu. În acest caz, administratorul de sistem va avea nevoie
pentru a regla sistemul de fișiere.

Supracomandarea depozit copii
Dacă faceți modificări la un fișier la nivel local, makepp își va da seama de obicei de acest lucru și
recompilați fișierul folosind copia locală, mai degrabă decât copia depozitului.

Dacă utilizați un depozit pentru a menține o bază de cod centrală și aveți dezvoltatori
lucrând la copii locale care conțin doar fișierele pe care le-au modificat, o problemă care
apare este: ce se întâmplă dacă un dezvoltator dorește să elimine un fișier din construcția sa locală, dar
depozitul încă îl conține? Dacă dezvoltatorul elimină copia locală, makepp o va face
puneți cu plăcere copia din depozit și construirea va continua ca și cum fișierul
a existat.

O tehnică (din păcate, nu pentru utilizatorul root) pentru această problemă este să creați fișierul pe care îl doriți
să nu includă în procesul de construire conținut ilizibil, așa:

fișierul chmod a-rw care urmează să fie exclus

Acest lucru va împiedica makepp să-l încorporeze din depozit. Makepp include, de asemenea
cod special, astfel încât fișierele care nu pot fi citite să nu se potrivească cu caracterele metalice sau regulile de model.

În mod similar, pentru a preveni makepp să încorporeze un întreg subdirector, creați un local
director care are același nume, dar nu poate fi scris. Dacă doriți ca makepp să ignore
directorul în întregime, apoi faceți-l și el imposibil de citit. (Se caută directoare numai pentru citire, dar
țintele din ele nu sunt de obicei construite.)

Cealaltă modalitate de a face acest lucru este apelarea makepp cu una sau mai multe opțiuni de excludere:

mpp -R /cale/la/rep --dont-read=/cale/la/rep/fișier-de-a-fi-exclus

nu face utilizare arhive pentru fișiere care poate să Schimbare!
Nu încercați să utilizați un depozit pentru un fișier care face parte din compilația dvs. De exemplu, tu
ar putea fi tentat să încerce să folosească depozitele pentru a pune toate fișierele publice .h în același
director, astfel:

# makefile de nivel superior
depozit include=module1/include
depozit include=module2/include
depozit include=module3/include
depozit include=module4/include

Aceasta probabil că nu este o idee bună dacă Orice a .h fișierele sunt ele însele ieșiri ale unui
program (de exemplu, yacc sau alt program care scuipă cod sursă C), deoarece makepp
presupune că fișierele din depozite nu se schimbă niciodată. Dacă construcția are nevoie include/xyz.h și
module2/include/xyz.h de fapt, trebuie să fie produs de un program, makepp nu va ști
pentru a rula programul. Este mai bine să folosești o tehnică ca aceasta pentru a-ți pune tot .h fișiere
într-un director include comun:

# module1/Makeppfile
../include/%.h : include/%.h
&cp $(intrare) $(ieșire)
# Puteți, de asemenea, (mai eficient, dar problematic pe Windows) să faceți următoarele:
# &ln -r $(intrare) $(ieșire)

Makepp ar putea încerca în continuare să construiască fișiere care se întâmplă să fie într-un depozit dacă ceva vă întreabă
pentru ei direct, dar nu le va construi on folosul a directorului local. Rezultatul
Acest lucru poate fi destul de confuz, deoarece poate duce la existența unei legături simbolice de depozit
utilizat în timp ce ținta de depozit este învechită, dar ținta respectivă ar putea fi actualizată mai târziu
în construcție. Puteți preveni acest lucru fie asigurându-vă că
se face referire la depozit prin calea depozitului sau asigurându-vă că acolo
este, de asemenea, o regulă locală pentru toate fișierele de depozit generate.

O altă modalitate de a evita recompilarea fișierelor identice în directoare diferite este utilizarea a
construiți cache (consultați makepp_build_cache pentru detalii). Un cache de compilare nu are
restricție conform căreia fișierul nu se poate modifica.

Utilizați makepp_repositories online folosind serviciile onworks.net