makepp_repositories - Online w chmurze

PROGRAM:

IMIĘ

makepp_repositories -- Jak używać repozytoriów do kompilacji wariantów, do utrzymywania a
centralny zbiór źródeł i inne rzeczy

OPIS

A składnica jest katalogiem lub hierarchią katalogów poza domyślnym katalogiem, który
zawiera pliki, których potrzebuje makefile w bieżącym drzewie katalogów. Makepp może
automatycznie łącz pliki z repozytorium do bieżącego drzewa katalogów, jeśli są
potrzebne. Repozytoria zapewniają podobną funkcjonalność do zmiennej „VPATH”, ale (w przeciwieństwie do
"VPATH" w innych wersjach make) nie musisz robić nic specjalnego w swoim makefile
aby zmusić ich do pracy.

Repozytoria są określane za pomocą opcji wiersza poleceń "-R" lub "--repository" lub za pomocą
oświadczenie „repozytorium” w pliku makefile. Pamiętaj, że jeśli masz zwyczaj dzwonić do makepp
w różnych podkatalogach twojego drzewa budowania łatwo jest przypadkowo ponownie zaimportować a
repozytorium gdzie indziej. Jako zabezpieczenie przed tym, jeśli używasz Plik rootMakepp, makijaż
odmówi uruchomienia, jeśli znajdzie jeden powyżej lub poniżej miejsca, w którym zostałby zaimportowany.

Jest to trochę porównywalne do systemów plików unii systemu operacyjnego (unionfs...)
bieżący katalog jest jak warstwa zapisywalna najwyższego poziomu. Wszystkie repozytoria są jak
niższe warstwy tylko do odczytu.

Repozytoria są przydatne w kilku różnych sytuacjach:

· Gdy chcesz umieścić swój obiekt i pliki wykonywalne w osobnym katalogu, ale
plik makefile jest napisany tak, aby umieścić je w tym samym katalogu co źródła.

· Gdy chcesz zbudować ten sam program na dwa różne sposoby (np. z dwoma różnymi
zestawy opcji kompilacji lub dla dwóch różnych architektur).

· Gdy nie masz prawa zapisu do całości lub części drzewa źródłowego.

· Gdy kilku programistów pracuje nad tym samym projektem i istnieje wspólne źródło
repozytorium zawierające wszystkie źródła projektu. Każdy programista może tylko modyfikować
pliki, które musi zmienić w swoim lokalnym katalogu bez wpływu na inne
programiści, a makepp automatycznie pobierze niezmodyfikowane pliki ze źródła
magazyn.

Implementacja repozytoriów Makepp nie wymaga przepisywania poleceń kompilacji
w ogóle, w przeciwieństwie do (na przykład) repozytoriów w przeciw. Makepp umieszcza dowiązanie symboliczne w
katalog, w którym oczekuje tego polecenie. Dopóki polecenie nie odnosi się do
katalogi bezwzględne, dokładnie to samo polecenie powłoki będzie działać z plikami z repozytorium.
Oznacza to, że działa nie tylko z poleceniami kompilacji, ale także z każdym rodzajem polecenia, którego używasz
może pomyśleć o wstawieniu pliku makefile.

Makepp ma inny rodzaj mechanizmu zwany a budować Pamięć podręczna co rozwiązuje niektóre z tych samych
rodzaje problemów jako repozytoria w inny sposób. W zależności od problemu, kompilacja
pamięć podręczna może być bardziej użyteczna niż repozytorium. Zobacz makepp_build_cache, aby uzyskać informacje na temat
build cache i porównanie buildów i repozytoriów.

Przykłady
Repozytoria najlepiej wyjaśnia kilka przykładów tego, co możesz zrobić.

Inny kompilacja Opcje

Załóżmy, że masz prosty program z plikiem makefile, który wygląda mniej więcej tak:

CFLAGI = -O2
OBIEKTY = ao bo co
mój_program: $(OBIEKTY)
cc $(wejścia) -o $(wyjście)

%.o: %.c
cc $(CFLAGS) -c $(wejście) -o $(wyjście)

Ten plik makefile umieszcza pliki „ao”, „bo”, „co” i „my_program” w tym samym katalogu
jako pliki źródłowe.

Czasami chcesz umieścić pliki binarne w osobnym katalogu. Na przykład ty
możesz zbudować swój program na kilku różnych architekturach, a ty nie chcesz binarki
pliki na jednej architekturze, które mają zostać zastąpione plikami binarnymi na drugiej. Albo możesz
chcesz dokonać tymczasowej zmiany i ponownie skompilować bez wymazywania poprzedniej kompilacji
wyniki. Bez repozytoriów musiałbyś zmodyfikować swój plik makefile, aby umieścić
przedmioty w innym miejscu.

Jednak z repozytorium nie musisz w ogóle dotykać swojego pliku makefile. Weź pod uwagę
następująca sekwencja poleceń:

% cd moje_źródło_programu
% makepp # Kompiluje używając powyższego makefile i
# pliki obiektowe trafiają do katalogu
# moje_źródło_programu.
% Płyta CD ..
% mkdir binary-debug # Stwórz czysty katalog do budowania
% cd binary-debug # ten sam program z różnymi opcjami.
% makepp -R ../moje_źródło_programu CFLAGS=-g
# Teraz obiekty trafiają do debugowania binarnego.

Pierwsze polecenie makepp kompiluje pliki źródłowe z optymalizacją i umieszcza obiekty
do katalogu "mój_źródło_programu", ponieważ właśnie do tego ma służyć makefile
robić. Teraz chcemy przebudować program, ale chcemy zmienić wartość „CFLAGS” na
skompilować do debugowania. W wierszu poleceń podajemy nową wartość „CFLAGS”, a także
powiedz makeppowi, że katalog "my_program_source" jest repozytorium, używając opcji "-R".

Za każdym razem, gdy makepp zdaje sobie sprawę, że potrzebuje pliku, którego jeszcze nie ma w bieżącym
katalog, szuka w repozytorium. W tym przypadku najpierw szuka pliku makefile,
który nie istnieje w podkatalogu "binary-debug". Tworzy więc dowiązanie symboliczne do
go z pliku makefile w "moj_źródło_programu", a następnie odczytuje plik makefile. Potem to
zauważa, że ​​potrzebuje pliku "ac" do zbudowania "ao", więc łączy się w "ac"
z repozytorium. Jeśli „ac” zawiera jakiekolwiek pliki zawarte w „moj_źródło_programu”, to
one również zostaną automatycznie połączone. Uwaga: te linki są przydatne do rzeczy
jak debugowanie, ale jeśli ich nie lubisz, "makeppclean -R" może je usunąć.

Uruchomienie polecenia budowania w "binary-debug" nie dotknie żadnego z plików w
„moje_źródło_programu”. Tak więc z tego samego zestawu plików źródłowych masz teraz dwa różne
kopie programu, jedna skompilowana z optymalizacją i jedna skompilowana do debugowania. I
stało się to bez dotykania pliku makefile.

Zaleta korzystania z repozytoriów zamiast zwykłej ponownej kompilacji i nadpisywania
oryginalne binaria są takie, że teraz, jeśli naprawimy nasze błędy i chcemy wrócić do zoptymalizowanych
wersji, nie musimy wszystkiego przekompilowywać. Ponieważ oryginalne pliki obiektowe są nadal
wokół, a większość z nich jest nadal aktualna, możemy zaoszczędzić sporo czasu na ponownej kompilacji.
Nie robi to dużej różnicy, gdy zaangażowane są tylko trzy pliki źródłowe, ale dla
większa kompilacja, której ukończenie zajmuje minuty lub godziny, oszczędność czasu programisty i
frustracja może być znacząca.

Przebudowa pierwszej filet w a moll modyfikacja do dotychczasowy kompilacja Polecenia

Makepp nie pobiera tylko plików źródłowych z repozytorium. Jeśli pliki obiektów w
repozytorium nie wymaga przebudowy, będzie je wykorzystywało. Rozważmy na przykład niewielką
modyfikacja powyższego pliku makefile:

CFLAGI := -O2
A_CFLAGS := -O6 -pętle-funroll

OBIEKTY := ao bo co

mój_program: $(OBIEKTY)
cc $(wejścia) -o $(wyjście)

%.o: %.c
cc $(CFLAGS) -c $(wejście) -o $(wyjście)

ao: ac
cc $(A_CFLAGS) -c $(wejście) -o $(wyjście)

Chodzi o to, że "ao" zawiera kod krytyczny czasowo, więc jest kompilowany z wyższymi
optymalizacja niż reszta obiektów. Załóżmy teraz, że chcemy przetestować, jak bardzo różnią się od siebie
czas jest z różnymi opcjami kompilacji. Repozytorium również może w tym pomóc:

% cd moje_źródło_programu
% makepp # Kompiluje używając powyższego makefile i
# pliki obiektowe trafiają do katalogu
# moje_źródło_programu.
% Płyta CD ..
% mkdir no-unrolling # Utwórz czysty katalog do budowania
% cd bez rozwijania # tego samego programu z różnymi opcjami.
% makepp -R ../moje_źródło_programu A_CFLAGS=-O2
% Płyta CD ..
% czasu bez rozwijania/mój_program # Porównaj dwie wersje programu.
% czasu mój_program_źródło/mój_program

Makepp postępuje tak jak poprzednio, łącząc kopię pliku makefile, a następnie badając obiekt
pliki. Teraz tylko moduł „ao” wymaga ponownej kompilacji, ponieważ opcje dla „bo” i „co”
się nie zmieniły. Makepp zauważa, że ​​może używać "bo" i "co" z repozytorium, więc
po prostu łączy je. Jednak ponownie skompiluje "ao" w katalogu "bez rozwijania".
Po zakończeniu kompilacji dwie różne wersje programu mogą być:
porównywane.

Przebudowa w a moll modyfikacja do dotychczasowy źródło

Załóżmy teraz, że chcemy dokonać zmiany w „ac” i przetestować program przed i po
zmiana. Repozytoria mogą znowu pomóc. Rozważ tę sekwencję poleceń:

% mkdir zmodyfikowany-a
% cp moje_źródło_programu/ac zmodyfikowano-a
% cd zmodyfikowany-a
% emacs ac # Dokonaj kilku modyfikacji tylko w tym module.
% makepp -R ../moje_źródło_programu

Tutaj utworzyliśmy nowy katalog, który zawiera tylko pojedynczy plik źródłowy, który chcemy
modyfikować. Makepp pobiera teraz „ac” z podkatalogu „modified-a”, ale używa kopii
„b” i „c” z katalogu „moje_źródło_programu”. Bez zmiany żadnego z binarnych
pliki w "moj_źródło_programu", stworzyliśmy osobną kopię programu, który
uwzględnia nasze zmiany w „ac”. Jeśli są inni programiści korzystający ze źródeł w
„my_program_source”, nasze zmiany nie będą miały na nie wpływu.

Repozytoria mogą zatem służyć jako szybki sposób na budowanie wariantów programu, bez
dodawanie skomplikowanych warunków do pliku makefile. Żaden z plików w oryginale
katalogi są modyfikowane; są używane w razie potrzeby.

Korzystanie z a katalog hierarchia

Repozytorium to w rzeczywistości nie tylko pojedynczy katalog, to cała hierarchia katalogów.
Załóżmy, że używasz /nasza/biblioteka jako repozytorium. Ale już /nasza/biblioteka może zawierać wiele
podkatalogi, np. /nasza/biblioteka/gui i /nasza/biblioteka/sieć. Rozważ to polecenie:

% makepp -R /nasza/biblioteka

Wszelkie polecenia w pliku makefile, które odnoszą się do plików w katalogu ./sieć faktycznie
pobierz pliki z /nasza/biblioteka/sieći podobnie dla ./gui. Makepp automatycznie
tworzy wszystkie katalogi, które istnieją w repozytorium, ale nie znajdują się w bieżącym katalogu.

Łączenie do każdy miejsce in dotychczasowy filet system

Wszystkie powyższe przykłady pokazują pliki z repozytorium połączone z bieżącym
katalogu lub jego podkatalogów, ale tak naprawdę makepp może je połączyć w dowolne miejsce
w systemie plików, do którego masz dostęp do zapisu. Odbywa się to poprzez określenie
"-R nowa-lokalizacja=stara-lokalizacja".

Na przykład czasami jest trochę żmudne wpisanie następującego tekstu:

mkdir alternatywna kompilacja
cd alternatywna kompilacja
makepp -R ..

Możesz to wszystko zrobić jednym poleceniem, tak jak to:

makepp -R alternatywna budowa=. -F alternatywna kompilacja

"-F" lub "-makeppfile" zmienia się w tym katalogu przed załadowaniem pliku makefile. Musisz
podaj "-R" przed "-F". Zauważ, że ten przykład umieszcza nowe drzewo kompilacji wewnątrz
magazyn. To nie zadziała, jeśli użyjesz a Plik rootMakepp bo zabezpieczenia makepp
przed zagnieżdżonymi drzewami. Nie jest to również dobry pomysł, jeśli używasz **, bo jeśli kiedykolwiek zbudujesz
w repozytorium znajdzie również edytowane i wygenerowane pliki w tym poddrzewie.

Przypisanie innej lokalizacji w systemie plików może być również przydatne w przypadku bardziej skomplikowanych
kompilacje, w których istnieje kilka podkatalogów bibliotecznych. Na przykład, oto polecenie I
używałem do budowania wariantów jednego z moich programów:

% makepp -R test-build/seescape=/src/seescape \
-R kompilacja testowa/HLib=/src/HLib \
-R kompilacja testowa/H5pp=/src/H5pp \
-R qwt=/źródło/biblioteki_zewnętrzne/qwt \
-F kompilacja testowa/seescape

To polecenie ładuje pliki z czterech różnych repozytoriów, a następnie płyty CD do
./test-kompilacja/seescape i wykonuje tam plik makefile. Pliki zawarte w
drzewo katalogów zaczynające się od /src/seescape są połączone w ./test-kompilacja/seescape, w
innymi słowy, makepp tymczasowo połączy plik /src/seescape/gui/image_canvas.cxx do
./test-build/seescape/gui/image_canvas.cxx kiedy jest to potrzebne. To polecenie będzie działać nawet
jeśli katalog "test-build" jeszcze nie istnieje; makepp stworzy to za Ciebie. (Ale ty
należy określić opcje „-R” przed opcją „-F” w wierszu poleceń.)

Wielokrotność równoważny repozytoria

Załóżmy, że Twój projekt jest zarządzany przez kilka dość autonomicznych grup. Mógłbyś mieć jeden
kompletne repozytorium ze wszystkimi źródłami w stanie produkcyjnym lub przynajmniej
pomyślnie przetestowany. Każda grupa może mieć w większości puste repozytorium z (częścią)
ta sama struktura, zawierająca pliki członków grupy, została zakończona.

Bieżące katalogi programistów będą zawierały pliki, nad którymi nadal pracują. Grupa
repozytorium będzie pierwszym podanym, a ostatnim będzie repozytorium produkcyjne, aby
dostarcza pliki nie znalezione w repozytorium grupy:

$ makepp -R/ścieżka/do/grupy/repozytorium -R/ścieżka/do/produkcji/repozytorium

Ponieważ jest to prawdopodobnie dość statyczne dla tego katalogu, możesz chcieć umieścić plik
.makeprc u podstawy o następującej treści:

-R/ścieżka/do/grupy/repozytorium -R/ścieżka/do/produkcji/repozytorium

Lub, zakładając, że ma ustaloną ścieżkę, możesz napisać do swojego pliku makefile:

repozytorium /ścieżka/do/produkcji/repozytorium

a ponieważ opcje są widoczne przed odczytaniem plików makefile, możesz wtedy wywołać just

$ makepp -R/ścieżka/do/grupy/repozytorium

Repozytoria as ustalony część of Twój budować system

Jeśli wiesz, że zawsze używasz jakiegoś repozytorium, możesz użyć "repozytorium" lub "vpath"
oświadczenia w twoim pliku makefile.

Ostrzeżenia w repozytoria
Kiedy dotychczasowy linki otrzymać in dotychczasowy droga

Do odnalezienia się w hierarchii plików i umożliwienia debugerowi znalezienia
źródła przydatne jest, aby linki były używane podczas budowania. Ale kiedy chcesz edytować a
pliku lub zsynchronizuj go ponownie z kontrolą wersji, linki mogą przeszkadzać. To jest
ponieważ system przemierza łącze i zapisuje do pliku w repozytorium. Chyba że
to twoje osobiste repozytorium używane tylko do oddzielania rzeczy, to może nie być to, co ty
chcieć.

Jako zabezpieczenie przed nieumyślnym nadpisaniem plików publicznych sugeruje się, aby:
źródła w repozytorium nie do zapisu. Może nawet nie wystarczyć, aby usunąć zapis
trochę, ponieważ system kontroli wersji, który nalega na zablokowanie plików do edycji
może to również zrobić, ale tymczasowo uczynić plik zapisywalnym podczas ponownej synchronizacji. Jeśli tak jest
w twoim przypadku repozytorium powinno w rzeczywistości należeć do innego użytkownika.

Istnieje kilka taktyk, aby to przezwyciężyć:

· Przechowuj edytowane źródła w repozytorium, oddzielnie od drzewa budowania. Zawsze, gdy
wstawiasz do tego plik, który został wcześniej pobrany z innego repozytorium
edytując repozytorium, makepp zauważy je i pobierze, pod warunkiem, że jest to
pierwsze określone repozytorium.

· Pamiętaj, aby usunąć dowolny plik, zanim utworzysz kopię do zapisu. Jeśli podążasz za
sugestia dotycząca zabezpieczenia powyżej, zapomnienie o tym spowoduje wyświetlenie komunikatu o błędzie, gdy
pismo. Aby Ci pomóc, następująca funkcja „usuń link” zastąpi jeden link kopią
połączonego pliku. Pierwszy wariant przeznaczony jest do wszystkich rodzajów muszli Bournish, drugi
jeden dla csh (lub przynajmniej tcsh):

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

· Jeśli czujesz, że ich nie potrzebujesz, możesz je wszystkie usunąć, kiedy tylko chcesz, np.
po każdym uruchomieniu makepp, prawdopodobnie w tle (w krótkiej lub długiej formie):

makeppclean --recurse --tylko linki-repozytorium
mppc -rR

nie budować in a składnica podczas posługiwać się

Repozytorium ma być tylko do odczytu, gdy jest używane jako repozytorium. Makepp będzie
nie działają poprawnie, jeśli zmienisz pliki w repozytorium w trakcie kompilacji.
Nocne kompilacje mogą być dla Ciebie w porządku, jeśli nikt inny nie korzysta w tym czasie z repozytorium. Przed
rozpoczyna kompilację, makepp pobiera listę wszystkich plików istniejących w repozytorium i
nigdy nie aktualizuje swojej listy, z wyjątkiem plików, które mają się pojawić.

Jeśli potrzebujesz repozytorium, które zmienia się w miarę tworzenia, możesz rozważyć makepp
budować mechanizm pamięci podręcznej (patrz makepp_build_cache). Alternatywnie możesz użyć „biednego człowieka
repozytorium: możesz umieścić wyraźne reguły w swoim pliku makefile, aby utworzyć miękkie linki, na przykład
to:

%.c : $(katalog_I_wish_was_a_repozytorium)/%.c
&ln -fs $(wejście) $(wyjście)

Działa to tylko dla plików źródłowych; nie możesz łatwo użyć tego do połączenia pliku, jeśli tak jest
już zbudowany w repozytorium, ale zbuduj go tutaj, jeśli nie jest jeszcze zbudowany, ponieważ tam
może być tylko jednym ze sposobów budowania pliku.

Zastosowanie tylko względny nazwy plików

Repozytoria działają całkowicie transparentnie if dotychczasowy makefile posługiwać się tylko względny nazwy plików.
W powyższym przykładzie jest w porządku, jeśli plik makefile w /src/seescape odnosi się do ../HLib, Ale
powyższe polecenie nie będzie działać zgodnie z oczekiwaniami, jeśli dotyczy /źródło/HLib. Jeśli potrzebujesz użyć
bezwzględne nazwy plików, możesz umieścić je w zmiennych make, a następnie nadpisać je na
wiersz poleceń, tak:

% makepp -R test-build/seescape=/src/seescape SEESCAPE=/home/holt/test-build/seescape \
-R kompilacja testowa/HLib=/src/HLib HLIB=/home/holt/kompilacja testowa/HLib \
-R kompilacja testowa/H5pp=/src/H5pp H5pp=/home/holt/kompilacja testowa/H5pp \
-R qwt=/src/biblioteki_zewnętrzne/qwt QWT=/home/holt/kompilacja-testowa/qwt \
-F kompilacja testowa/seescape

Powyższe będzie działać tak długo, jak długo katalog „HLib” będzie określany jako „$(HLIB)” we wszystkich
pliki makefile. Pamiętaj, że musisz określić bezwzględne ścieżki do katalogów, ponieważ
CD makepp do "test-build/seescape" przed odczytaniem pliku makepp. Prowadzi to do długich i
skomplikowane polecenia make; jeśli to możliwe, używaj ścieżek względnych.

Makepp musi wiedzieć Parę słów o cała kolekcja Zależności

Repozytoria nie będą działać, jeśli istnieją ukryte zależności, których makepp nie zna
o. (W rzeczywistości tworzenie kompilacji przy użyciu repozytoriów jest jednym ze sposobów sprawdzania, czy nie zostały zapomniane
zależności. Ale tylko do tego sprawdzenia nie łącz go z pamięcią podręczną kompilacji, ponieważ
pobranie czegoś tam, zamiast budowania, może ukryć zapomnianą zależność.)
Czasami te zależności mogą być dość subtelne. Na przykład libtool polecenie będzie
nie tylko tworzyć pliki ".lo" i ".la" wymienione w wierszu poleceń, ale także może:
utwórz podkatalog o nazwie ".libs", który zawiera rzeczywiste pliki obiektowe. Aby zapobiec
błędy w kompilacji, makepp odmawia połączenia w pliku ".la" z repozytorium. Mam nadzieję, że w
przyszłe libtool będzie lepiej obsługiwane.

Wiele ukrytych zależności związanych z kompilacją jest przechwytywanych przez skaner wiersza poleceń.
Jeśli twój kompilator używa popularnych flag kompilacji Uniksa (np. "-I", "-D" itp.), to
makepp zwykle dowie się, gdzie znajdują się wszystkie twoje pliki dołączane. Być może będziesz musiał być
uważaj, jeśli masz jakieś własne skrypty, które tworzą pliki, których makepp nie zna
o. Aby uzyskać prawidłowe kompilacje, niezwykle ważne jest, aby wymienić cała kolekcja cele i zależności
(lub określ je automatycznie, skanując).

Putting bezwzględny nazwy plików najnowszych programów

Repozytoria również nie będą działać, jeśli którykolwiek z zbudowanych plików zawiera bezwzględne nazwy plików w
je (np. jeśli któreś z twoich poleceń budujących wypisze bezwzględną nazwę pliku). Na przykład,
okazuje się, że pliki ".la" wyprodukowane przez libtool mają tę właściwość. (Jeśli spojrzysz na
zawartość pliku ".la" zobaczysz, że lista zależności zawiera wartości bezwzględne
nazwy plików.) Aby rozwiązać ten konkretny problem, makepp nie będzie linkował plików ".la"
z repozytorium; będzie nalegał na ich odbudowę.

Uniknąć Powiązanie in niepotrzebny katalogi

Repozytoria mogą działać wolno podczas uruchamiania i zużywać dużo pamięci, jeśli jest ich dużo
niepotrzebne pliki w repozytorium. Na przykład, jeśli używasz automatycznego kodu HTML
generator dokumentacji, który tworzy tysiące plików ".html" z twojego kodu źródłowego, ty
może nie chcieć umieszczać ich w podkatalogu katalogu, który jest używany jako repozytorium.
Lepiej umieścić je w zupełnie innym drzewie katalogów, więc repozytorium
mechanizm nie ładuje się w ich nazwach.

Zbyt Wiele Akta

Wadą repozytoriów jest to, że dowiązania symboliczne, które mechanizm repozytorium
zastosowań, to pojedyncze pliki (chociaż prawie nie zajmują miejsca na dysku). To nie jest prawdziwe
łącza, ale te nie mogą przekraczać granic systemu plików. W skrajnych przypadkach obecność
bardzo duża ilość dowiązań symbolicznych może prowadzić do wyczerpania ilości przewidzianych plików (tzw
i-węzły), mimo że pozostało dużo miejsca. W takim przypadku administrator będzie potrzebować
aby dostroić system plików.

Nadrzędny składnica kopie
Jeśli wprowadzisz jakiekolwiek modyfikacje w pliku lokalnie, makepp zwykle zda sobie z tego sprawę i
ponownie skompiluj plik, używając kopii lokalnej, a nie kopii repozytorium.

Jeśli używasz repozytorium do utrzymania centralnej bazy kodu i masz programistów
praca na lokalnych kopiach zawierających tylko zmodyfikowane przez nich pliki, jeden problem, który
pojawia się pytanie: co zrobić, jeśli programista chce usunąć plik ze swojej lokalnej kompilacji, ale
repozytorium nadal go zawiera? Jeśli deweloper usunie kopię lokalną, makepp
szczęśliwie umieść kopię z repozytorium, a kompilacja będzie przebiegać tak, jakby plik
istniało.

Jedną z technik (ale nie dla użytkownika root) na ten problem jest utworzenie odpowiedniego pliku
nie umieszczać w procesie kompilacji nieczytelnego, na przykład:

chmod a-rw plik-do-wykluczenia

Uniemożliwi to makepp włączenie go z repozytorium. Makepp zawiera również
specjalny kod, aby nieczytelne pliki nie pasowały do ​​symboli wieloznacznych ani reguł wzorców.

Podobnie, aby zapobiec włączaniu całego podkatalogu przez makepp, utwórz lokalny
katalog o tej samej nazwie, ale niezapisywalny. Jeśli chcesz, aby makepp zignorował
katalogu w całości, a następnie spraw, aby był nieczytelny. (Katalogi tylko do odczytu są przeszukiwane, ale
cele w nich zwykle nie są budowane.)

Innym sposobem na to jest wywołanie makepp z jedną lub kilkoma opcjami wykluczenia:

mpp -R /ścieżka/do/rep --dont-read=/ścieżka/do/rep/pliku-do-wykluczenia

nie posługiwać się repozytoria dla pliki który mogą zmiana!
Nie próbuj używać repozytorium dla pliku, który jest częścią twojej kompilacji. Na przykład ty
możesz pokusić się o użycie repozytoriów do umieszczenia wszystkich twoich publicznych plików .h w tym samym
katalog, taki jak ten:

# makefile najwyższego poziomu
repozytorium include=moduł1/include
repozytorium include=moduł2/include
repozytorium include=moduł3/include
repozytorium include=moduł4/include

To chyba nie jest dobry pomysł, jeśli każdy ukończenia .h pliki same w sobie są wyjściami
program (np. yacc lub inny program, który wypluwa kod źródłowy C), ponieważ makepp
zakłada, że ​​pliki w repozytoriach nigdy się nie zmieniają. Jeśli kompilacja potrzebuje uwzględnij/xyz.h,
moduł2/włącz/xyz.h faktycznie musi być wyprodukowany przez jakiś program, makepp nie będzie wiedział
uruchomić program. Lepiej jest użyć takiej techniki, aby umieścić wszystkie swoje .h pliki
do wspólnego katalogu include:

# moduł1/plik Makepp
../include/%.h : zawiera/%.h
&cp $(wejście) $(wyjście)
# Możesz również (bardziej wydajnie, ale problematycznie w systemie Windows) wykonać następujące czynności:
# &ln -r $(wejście) $(wyjście)

Makepp może nadal próbować budować pliki, które akurat znajdują się w repozytorium, jeśli coś o to poprosi
dla nich bezpośrednio, ale to ich nie zbuduje on w imieniu katalogu lokalnego. Wynik
może to być dość mylące, ponieważ może prowadzić do tego, że dowiązanie symboliczne do repozytorium jest
używany, gdy jego cel repozytorium jest nieaktualny, ale ten cel może zostać zaktualizowany później
w kompilacji. Możesz temu zapobiec, upewniając się, że:
o którym mowa w repozytorium tylko przez ścieżkę repozytorium lub upewniając się, że:
jest również lokalną regułą dla wszystkich generowanych plików repozytorium.

Innym sposobem uniknięcia ponownej kompilacji identycznych plików w różnych katalogach jest użycie a
buduj pamięć podręczną (zobacz makepp_build_cache po szczegóły). Pamięć podręczna kompilacji nie ma
ograniczenie, że plik nie może się zmienić.

Korzystaj z makepp_repositories online za pomocą usług onworks.net