makepp_repositories – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

makepp_repositories – So verwenden Sie Repositorys für Varianten-Builds, zum Verwalten von a
zentraler Quellensatz und andere Dinge

BESCHREIBUNG

A Quelle ist ein Verzeichnis oder eine Verzeichnishierarchie außerhalb des Standardverzeichnisses
enthält Dateien, die das Makefile im aktuellen Verzeichnisbaum benötigt. Makepp kann
Verknüpfen Sie Dateien aus dem Repository automatisch mit dem aktuellen Verzeichnisbaum, falls dies der Fall ist
erforderlich. Repositorys bieten ähnliche Funktionen wie die Variable „VPATH“, aber (im Gegensatz zu
„VPATH“ in anderen Versionen von make) müssen Sie nichts Besonderes an Ihrem Makefile vornehmen
um sie zum Arbeiten zu bringen.

Repositorys werden mit der Befehlszeilenoption „-R“ oder „--repository“ oder mit angegeben
„repository“-Anweisung im Makefile. Beachten Sie Folgendes: Wenn Sie die Angewohnheit haben, makepp aufzurufen
In verschiedenen Unterverzeichnissen Ihres Build-Baums kann es leicht passieren, dass a versehentlich erneut importiert wird
Repository woanders. Als Schutz davor, wenn Sie verwenden RootMakeppfile, makepp
verweigert den Start, wenn oberhalb oder unterhalb der Stelle, an der es importiert werden soll, eine gefunden wird.

Dies ist in gewisser Weise vergleichbar mit den Union-Dateisystemen des Betriebssystems (unionfs...).
Das aktuelle Verzeichnis ist wie die beschreibbare Ebene der höchsten Ebene. Alle Repositories sind wie
untere schreibgeschützte Ebenen.

Repositorys sind in verschiedenen Situationen nützlich:

· Wenn Sie Ihre Objekt- und ausführbaren Dateien in einem separaten Verzeichnis ablegen möchten, aber
Das Makefile wird so geschrieben, dass sie im selben Verzeichnis wie die Quellen abgelegt werden.

· Wenn Sie dasselbe Programm auf zwei verschiedene Arten erstellen möchten (z. B. mit zwei verschiedenen
Sätze von Kompilierungsoptionen oder für zwei verschiedene Architekturen).

· Wenn Sie keinen Schreibzugriff auf den gesamten oder einen Teil des Quellbaums haben.

· Wenn mehrere Entwickler an demselben Projekt arbeiten und eine gemeinsame Quelle vorhanden ist
Repository, das alle Quellen für das Projekt enthält. Jeder Entwickler kann nur Änderungen vornehmen
die Dateien, die er in seinem lokalen Verzeichnis ändern muss, ohne dass sich dies auf die anderen auswirkt
Entwickler, und makepp ruft automatisch die unveränderten Dateien aus der Quelle ab
Repository.

Die Implementierung von Repositorys durch Makepp erfordert kein Umschreiben der Build-Befehle
überhaupt, anders als (zum Beispiel) Repositories in Cons. Makepp setzt einen symbolischen Link in die
Verzeichnis, in dem der Befehl es erwartet. Solange sich der Befehl nicht darauf bezieht
Bei absoluten Verzeichnissen funktioniert der exakt gleiche Shell-Befehl auch mit Dateien aus einem Repository.
Dies bedeutet, dass es nicht nur für Kompilierungsbefehle funktioniert, sondern für alle Arten von Befehlen, die Sie erhalten
Ich kann mir vorstellen, Ihr Makefile einzufügen.

Makepp hat eine andere Art von Mechanismus namens a bauen Cache-Speicher was einige davon löst
Arten von Problemen als Repositorys auf andere Weise. Abhängig von Ihrem Problem ein Build
Cache kann nützlicher sein als ein Repository. Weitere Informationen finden Sie unter makepp_build_cache
Build-Caches und ein Vergleich von Build-Caches und Repositorys.

Beispiele
Repositories lassen sich am besten anhand einiger Beispiele erklären, was Sie tun können.

Verschiedene Zusammenstellung Optionen

Angenommen, Sie haben ein einfaches Programm mit einem Makefile, das etwa so aussieht:

CFLAGS = -O2
OBJEKTE = ao bo co
my_program: $(OBJECTS)
cc $(Eingaben) -o $(Ausgabe)

%.o: %.c
cc $(CFLAGS) -c $(Eingabe) -o $(Ausgabe)

Dieses Makefile legt die Dateien „ao“, „bo“, „co“ und „my_program“ im selben Verzeichnis ab
als Quelldateien.

Manchmal möchten Sie die Binärdateien in einem separaten Verzeichnis ablegen. Zum Beispiel du
Möglicherweise bauen Sie Ihr Programm auf mehreren verschiedenen Architekturen auf, und Sie möchten die Binärdatei nicht
Dateien auf einer Architektur werden durch die Binärdateien auf der anderen ersetzt. Oder Sie könnten es tun
Sie möchten eine vorübergehende Änderung vornehmen und neu kompilieren, ohne die vorherige Kompilierung zu löschen
Ergebnisse. Ohne Repositorys müssten Sie Ihr Makefile ändern, um die zu platzieren
Gegenstände an anderer Stelle.

Bei einem Repository müssen Sie Ihr Makefile jedoch überhaupt nicht verändern. Bedenke die
folgende Befehlsfolge:

% cd my_program_source
% makepp # Erstellt mit dem oben genannten Makefile und
# Objektdateien werden in das Verzeichnis verschoben
# my_program_source.
% CD ..
% mkdir Binary-Debug # Erstellen Sie ein sauberes Verzeichnis zum Erstellen des
% cd Binary-Debug # dasselbe Programm mit unterschiedlichen Optionen.
% makepp -R ../my_program_source CFLAGS=-g
# Jetzt gehen Objekte in den Binär-Debug.

Der erste makepp-Befehl kompiliert die Quelldateien mit Optimierung und legt die Objekte ab
in das Verzeichnis „my_program_source“, denn das ist es, was das Makefile tun soll
Tun. Jetzt wollen wir das Programm neu erstellen, aber den Wert von „CFLAGS“ in ändern
zum Debuggen kompilieren. Wir geben den neuen Wert von „CFLAGS“ in der Befehlszeile an und wir auch
Teilen Sie Makepp mit der Option „-R“ mit, dass das Verzeichnis „my_program_source“ ein Repository ist.

Jedes Mal erkennt Makepp, dass es eine Datei benötigt, die es noch nicht im aktuellen Verzeichnis hat
Verzeichnis, es sucht im Repository. In diesem Fall wird zunächst nach dem Makefile gesucht,
was im Unterverzeichnis „binary-debug“ nicht vorhanden ist. Es entsteht also eine symbolische Verbindung zu
es aus dem Makefile in „my_program_source“ und liest dann das Makefile ein. Dann es
bemerkt, dass es die Datei „ac“ benötigt, um „ao“ zu erstellen, und verlinkt daher in „ac“
aus dem Repository. Wenn „ac“ alle in „my_program_source“ enthaltenen Dateien enthält, dann
diese werden automatisch ebenfalls eingebunden. Hinweis: Diese Links sind für Dinge nützlich
wie Debuggen, aber wenn Sie sie nicht mögen, können Sie sie mit „makeppclean -R“ entfernen.

Das Ausführen des Build-Befehls in „binary-debug“ hat keinen Einfluss auf die darin enthaltenen Dateien
„meine_Programmquelle“. Somit haben Sie aus demselben Satz Quelldateien jetzt zwei verschiedene
Kopien des Programms, eine mit Optimierung kompiliert und eine zum Debuggen kompiliert. Und
Dies geschah, ohne dass das Makefile überhaupt berührt wurde.

Der Vorteil der Verwendung von Repositorys anstelle des einfachen Neukompilierens und Überschreibens
Die ursprünglichen Binärdateien sind jetzt, wenn wir unsere Fehler beheben und zur optimierten Version zurückkehren möchten
Version müssen wir nicht alles neu kompilieren. Da die ursprünglichen Objektdateien noch vorhanden sind
herumliegen und die meisten noch gültig sind, können wir bei der Neukompilierung viel Zeit sparen.
Dies macht keinen großen Unterschied, wenn nur drei Quelldateien beteiligt sind, aber für eine
Größere Builds, deren Fertigstellung Minuten oder Stunden dauert, die Einsparungen an Programmiererzeit und
Frustration kann erheblich sein.

Wiederaufbau dank One Datei mit a Moll Modifikation zu die Zusammenstellung Befehle

Makepp ruft nicht nur Quelldateien aus dem Repository ab. Wenn die Objektdateien in der
Das Repository muss nicht neu erstellt werden, es wird sie verwenden. Betrachten Sie zum Beispiel eine leichte
Änderung am obigen Makefile:

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

OBJEKTE := ao bo co

my_program: $(OBJECTS)
cc $(Eingaben) -o $(Ausgabe)

%.o: %.c
cc $(CFLAGS) -c $(Eingabe) -o $(Ausgabe)

ao: ac
cc $(A_CFLAGS) -c $(Eingabe) -o $(Ausgabe)

Die Idee ist, dass „ao“ den zeitkritischen Code enthält und daher mit höherer Kompilierung kompiliert wird
Optimierung als der Rest der Objekte. Nehmen wir nun an, wir wollen testen, wie unterschiedlich es ist
Das Timing erfolgt mit unterschiedlichen Kompilierungsoptionen. Auch hier kann ein Repository helfen:

% cd my_program_source
% makepp # Erstellt mit dem oben genannten Makefile und
# Objektdateien werden in das Verzeichnis verschoben
# my_program_source.
% CD ..
% mkdir no-unrolling # Erstellen Sie ein sauberes Verzeichnis zum Erstellen des
% cd no-unrolling # gleiches Programm mit unterschiedlichen Optionen.
% makepp -R ../my_program_source A_CFLAGS=-O2
% CD ..
% time no-unrolling/my_program # Vergleichen Sie die beiden Versionen des Programms.
% Zeit my_program_source/my_program

Makepp geht wie zuvor vor, bindet eine Kopie des Makefiles ein und untersucht dann das Objekt
Dateien. Jetzt muss nur noch das Modul „ao“ neu kompiliert werden, da die Optionen für „bo“ und „co“
haben sich nicht geändert. Makepp bemerkt, dass es „bo“ und „co“ aus dem Repository verwenden kann, also
Es verknüpft diese lediglich. Allerdings wird „ao“ im Verzeichnis „no-unrolling“ neu kompiliert.
Sobald die Kompilierung abgeschlossen ist, können die beiden verschiedenen Versionen des Programms erstellt werden
Benchmarking.

Wiederaufbau mit a Moll Modifikation zu die Quelle

Nehmen wir nun an, wir möchten eine Änderung an „ac“ vornehmen und das Programm vorher und nachher einem Benchmarking unterziehen
der Wechsel. Repositories können wieder helfen. Betrachten Sie diese Befehlsfolge:

% mkdir geändert-a
% cp my_program_source/ac Modified-a
% cd modifiziert-a
% emacs ac # Nehmen Sie einige Änderungen nur an diesem Modul vor.
% makepp -R ../my_program_source

Hier haben wir ein neues Verzeichnis erstellt, das nur die einzelne Quelldatei enthält, die wir benötigen
ändern. Makepp übernimmt nun „ac“ aus dem Unterverzeichnis „modified-a“, verwendet aber die Kopien von
„b“ und „c“ aus dem Verzeichnis „my_program_source“. Ohne die Binärdatei zu ändern
Dateien in „my_program_source“ haben wir eine separate Kopie des Programms erstellt
enthält unsere Änderungen an „ac“. Wenn es andere Entwickler gibt, die die Quellen in verwenden
„my_program_source“, sie sind von unseren Änderungen nicht betroffen.

Repositories können daher als schnelle Möglichkeit zum Erstellen von Varianten eines Programms verwendet werden, ohne dass dies erforderlich ist
Hinzufügen komplizierter Bedingungen zum Makefile. Keine der Dateien im Original
Verzeichnis werden geändert; Sie werden nach Bedarf verwendet.

Die richtigen a Verzeichnis Hierarchie

Ein Repository ist eigentlich nicht nur ein einzelnes Verzeichnis, sondern eine ganze Verzeichnishierarchie.
Angenommen, Sie verwenden /unsere/bibliothek als Aufbewahrungsort. Jetzt /unsere/bibliothek kann durchaus viele enthalten
Unterverzeichnisse, z. B. /our/library/gui und /unsere/bibliothek/netzwerk. Betrachten Sie diesen Befehl:

% makepp -R /our/library

Alle Befehle im Makefile, die auf Dateien im Verzeichnis verweisen ./Netzwerk wird eigentlich
Holen Sie sich Dateien von /unsere/bibliothek/netzwerk, und ähnlich für ./gui. Makepp automatisch
erstellt alle Verzeichnisse, die im Repository, aber nicht im aktuellen Verzeichnis vorhanden sind.

Linking zu für Ort in die Datei fragst

Alle oben genannten Beispiele zeigen Dateien aus einem Repository, die mit dem aktuellen verknüpft werden
Verzeichnis oder seine Unterverzeichnisse, aber Sie können Makepp tatsächlich an jede beliebige Stelle verlinken lassen
in dem Dateisystem, auf das Sie Schreibzugriff haben. Dies geschieht durch Angabe
„-R neuer-Standort=alter-Standort“.

Manchmal ist es beispielsweise etwas mühsam, Folgendes einzugeben:

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

Sie können alles mit einem Befehl erledigen, etwa so:

makepp -R alternative-build=. -F alternativer Build

„-F“ oder „-makeppfile“ wechselt in dieses Verzeichnis, bevor das Makefile geladen wird. Du musst
Geben Sie „-R“ vor „-F“ an. Beachten Sie, dass in diesem Beispiel der neue Build-Baum in die Datei eingefügt wird
Repository. Das funktioniert nicht, wenn Sie a verwenden RootMakeppfile weil makepp sichert
gegen verschachtelte Bäume. Es ist auch keine gute Idee, wenn Sie es verwenden **, denn wenn du jemals baust
Im Repository findet es in diesem Teilbaum auch bearbeitete und generierte Dateien.

Bei komplizierteren Problemen kann es auch sinnvoll sein, einen anderen Speicherort im Dateisystem zuzuweisen
builds, wo es mehrere Bibliotheksunterverzeichnisse gibt. Hier ist zum Beispiel ein Befehl I
habe Varianten eines meiner Programme erstellt:

% 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

Dieser Befehl lädt Dateien aus vier verschiedenen Repositorys und kopiert sie dann in das
./test-build/seescape Verzeichnis und führt dort das Makefile aus. In der Datei enthaltene Dateien
Verzeichnisbaum beginnend mit /src/seescape sind verlinkt ./test-build/seescape. in
Mit anderen Worten, makepp verknüpft die Datei vorübergehend /src/seescape/gui/image_canvas.cxx zu
./test-build/seescape/gui/image_canvas.cxx wenn es gebraucht wird. Dieser Befehl funktioniert sogar
wenn das Verzeichnis „test-build“ noch nicht existiert; makepp erstellt es für Sie. (Aber du
müssen die Optionen „-R“ vor der Option „-F“ in der Befehlszeile angeben.)

Mehrere äquivalent Repositories

Angenommen, Ihr Projekt wird von mehreren weitgehend autonomen Gruppen verwaltet. Du könntest eins haben
vollständiges Repository mit allen Quellen, so wie sie sich in der Produktion befinden oder zumindest
erfolgreich getestet. Jede Gruppe kann ein größtenteils leeres Repository mit (einem Teil davon) haben
Dieselbe Struktur, die die Dateien enthält, deren Entwicklung die Gruppenmitglieder abgeschlossen haben.

Die aktuellen Verzeichnisse der Entwickler enthalten die Dateien, an denen sie noch arbeiten. Die Gruppe
Das Repository wird als erstes angegeben und das Produktions-Repository als letztes
Es stellt die Dateien bereit, die nicht im Gruppen-Repository gefunden wurden:

$ makepp -R/Pfad/zu/Gruppe/Repository -R/Pfad/zu/Produktion/Repository

Da dies für dieses Verzeichnis wahrscheinlich ziemlich statisch ist, möchten Sie möglicherweise eine Datei ablegen
.makepprc im Kern mit folgendem Inhalt:

-R/Pfad/zur/Gruppe/Repository -R/Pfad/zur/Produktion/Repository

Unter der Annahme, dass es einen festen Pfad hat, könnten Sie auch in Ihr Makefile schreiben:

Repository /Pfad/zu/Produktion/Repository

und da Optionen angezeigt werden, bevor Makefiles gelesen werden, können Sie sie dann einfach aufrufen

$ makepp -R/path/to/group/repository

Aufbewahrungsorte as fixiert Teil of Wir koordinieren den Versand bauen fragst

Wenn Sie wissen, dass Sie immer ein Repository verwenden, können Sie „repository“ oder „vpath“ verwenden.
Anweisungen in Ihrem Makefile.

Vorsichtsmaßnahmen mit Repositories
Wann die Links bekommen in die Weg,

Um sich in Ihrer Dateihierarchie zurechtzufinden und dem Debugger das Finden zu ermöglichen
Quellen ist es nützlich, die Links beim Erstellen zu verwenden. Aber wenn Sie a bearbeiten möchten
Wenn Sie die Datei aktualisieren oder mit Ihrer Versionskontrolle erneut synchronisieren, können die Links stören. Das ist
weil das System den Link durchläuft und in die Datei im Repository schreibt. Es sei denn
Es ist Ihr persönlicher Aufbewahrungsort, der nur dazu dient, Dinge auseinanderzuhalten. Das ist vielleicht nicht das, was Sie tun
wollen.

Als Schutz gegen unbeabsichtigtes Überschreiben öffentlicher Dateien wird empfohlen, Folgendes vorzunehmen:
Quellen im Repository nicht beschreibbar. Möglicherweise reicht es nicht einmal aus, den Schreibvorgang zu entfernen
Bit, weil ein Versionskontrollsystem darauf besteht, dass Sie die Dateien für die Bearbeitung sperren
könnte das auch tun, aber die Datei vorübergehend beschreibbar machen, während sie erneut synchronisiert wird. Wenn das so ist
In Ihrem Fall müsste das Repository eigentlich einem anderen Benutzer gehören.

Es gibt ein paar Taktiken, um dies zu überwinden:

· Bewahren Sie die von Ihnen bearbeiteten Quellen in einem Repository getrennt von Ihrem Build-Baum auf. Wann immer
Hier legen Sie eine Datei ab, die zuvor aus einem anderen Repository geholt wurde
Wenn Sie das Repository bearbeiten, wird makepp es bemerken und es von dort abrufen, sofern es das ist
erstes Repository, das Sie angeben.

· Denken Sie daran, alle Dateien zu löschen, bevor Sie eine Kopie zum Schreiben erstellen. Wenn Sie dem folgen
Wenn Sie den oben genannten Schutzvorschlag beachten, wird bei Nichtbeachtung eine Fehlermeldung angezeigt
Schreiben. Um Ihnen zu helfen, ersetzt die folgende Funktion „delink“ einen Link durch eine Kopie
der verlinkten Datei. Die erste Variante ist für alle Arten von Bournish-Muscheln, die zweite
eine für csh (oder zumindest tcsh):

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

· Wenn Sie das Gefühl haben, dass Sie sie nicht benötigen, können Sie sie jederzeit alle löschen, z
nach jedem Makepp-Lauf, möglicherweise im Hintergrund (entweder Kurz- oder Langform):

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

Nicht bauen in a Quelle im -

Ein Repository soll schreibgeschützt sein, während es als Repository verwendet wird. Makepp wird es tun
nicht funktionieren ordnungsgemäß, wenn Sie während eines Builds Dateien in Ihrem Repository ändern.
Nächtliche Builds können für Sie in Ordnung sein, wenn zu diesem Zeitpunkt niemand anderes das Repository nutzt. Vor
Es startet den Build, makepp ruft eine Liste aller im Repository vorhandenen Dateien ab und
aktualisiert nie seine Liste, mit Ausnahme der Dateien, die erwartet werden.

Wenn Sie ein Repository benötigen, das sich beim Erstellen ändert, sollten Sie makepps in Betracht ziehen
Build-Cache-Mechanismus (siehe makepp_build_cache). Alternativ können Sie auch einen „armen Mann“ verwenden
Repository“: Sie können explizite Regeln in Ihr Makefile einfügen, um die Softlinks zu erstellen, z
Dies:

%.c : $(directory_I_wish_was_a_repository)/%.c
&ln -fs $(Eingabe) $(Ausgabe)

Dies funktioniert nur für Quelldateien; Sie können dies nicht einfach zum Verknüpfen einer Datei verwenden, wenn dies der Fall ist
bereits im Repository erstellt, aber erstellen Sie es hier, wenn es nicht bereits erstellt wurde, da dort
darf nur eine Möglichkeit sein, eine Datei zu erstellen.

Nutzen Sie einzige relativ Dateinamen

Repositories arbeiten völlig transparent if die Makefiles - einzige relativ Dateinamen.
Im obigen Beispiel ist es in Ordnung, wenn das Makefile in /src/seescape bezieht sich auf ../HLib, Aber die
Der obige Befehl funktioniert nicht wie erwartet, wenn er darauf verweist /src/HLib. Wenn Sie verwenden müssen
Bei absoluten Dateinamen können Sie sie in Make-Variablen einfügen und sie dann auf der Datei überschreiben
Befehlszeile, etwa so:

% 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

Das Obige funktioniert, solange das Verzeichnis „HLib“ in allen als „$(HLIB)“ bezeichnet wird
Makefiles. Beachten Sie, dass Sie absolute Pfade für die Verzeichnisse angeben müssen, denn
makepp-CDs auf „test-build/seescape“, bevor Sie das Makefile lesen. Dies führt zu langen und
komplizierte Make-Befehle; Verwenden Sie nach Möglichkeit relative Pfade.

Makepp sollen kennt Über mich alle Abhängigkeiten

Repositorys funktionieren nicht, wenn versteckte Abhängigkeiten vorhanden sind, die makepp nicht kennt
um. (Tatsächlich ist die Erstellung eines Builds mithilfe von Repositorys eine Möglichkeit, nach vergessenen Dateien zu suchen
Abhängigkeiten. Aber kombinieren Sie es nur für diese Überprüfung nicht mit einem Build-Cache, da
Etwas dort abzurufen, anstatt es zu erstellen, könnte eine vergessene Abhängigkeit verbergen.)
Manchmal können diese Abhängigkeiten ziemlich subtil sein. Zum Beispiel die libtool Befehl wird
Erstellen Sie nicht nur „.lo“- und „.la“-Dateien wie in der Befehlszeile aufgeführt, sondern möglicherweise auch
Erstellen Sie ein Unterverzeichnis mit dem Namen „.libs“, das die eigentlichen Objektdateien enthält. Verhindern
Build-Fehler, makepp weigert sich, eine „.la“-Datei aus einem Repository einzubinden. Hoffentlich drin
Das zukünftige libtool wird besser unterstützt.

Viele versteckte Abhängigkeiten im Zusammenhang mit der Kompilierung werden vom Befehlszeilenscanner abgefangen.
Wenn Ihr Compiler die üblichen Unix-Kompilierungsflags verwendet (z. B. „-I“, „-D“ usw.), dann
makepp findet normalerweise heraus, wo sich alle Ihre Include-Dateien befinden. Möglicherweise müssen Sie es sein
Seien Sie vorsichtig, wenn Sie selbst erstellte Skripte haben, die Dateien erstellen, die makepp nicht kennt
um. Für korrekte Builds ist die Auflistung von entscheidender Bedeutung alle Ziele und Abhängigkeiten
(oder durch Scannen automatisch ermitteln).

Putting Absolute Dateinamen in Programme

Repositorys funktionieren auch nicht, wenn eine der erstellten Dateien absolute Dateinamen enthält
sie (z. B. wenn einer Ihrer Build-Befehle einen absoluten Dateinamen ausgibt). Zum Beispiel,
Es stellt sich heraus, dass die „.la“-Dateien von erstellt wurden libtool habe diese Eigenschaft. (Wenn man sich das anschaut
Im Inhalt der Datei „.la“ sehen Sie, dass die Abhängigkeitsliste absolute enthält
Dateinamen.) Um dieses spezielle Problem zu lösen, verknüpft makepp keine „.la“-Dateien
aus einem Repository; es wird darauf bestehen, sie wieder aufzubauen.

Vermeiden Linking in unnötig Verzeichnisse

Repositorys können beim Start langsam sein und viel Speicher verbrauchen, wenn viele vorhanden sind
unnötige Dateien im Repository. Wenn Sie beispielsweise ein automatisches HTML verwenden
Dokumentationsgenerator, der aus Ihrem Quellcode Tausende von „.html“-Dateien erstellt
Möglicherweise möchten Sie sie nicht in einem Unterverzeichnis eines Verzeichnisses ablegen, das als Repository verwendet wird.
Es ist besser, sie vollständig in einem anderen Verzeichnisbaum abzulegen, also im Repository
Mechanismus wird nicht in ihren Namen geladen.

Too Viele Mappen

Der Nachteil von Repositorys besteht darin, dass der Repository-Mechanismus symbolische Links darstellt
verwendet werden, sind einzelne Dateien (obwohl sie fast keinen Speicherplatz beanspruchen). Das ist anders als echt
Links, aber diese können Dateisystemgrenzen nicht überschreiten. In extremen Fällen ist das Vorhandensein von
Sehr viele symbolische Links können dazu führen, dass die Anzahl der vorgesehenen Dateien (sog
Inodes), obwohl noch viel Platz übrig ist. In diesem Fall benötigt der Systemadministrator
um das Dateisystem zu optimieren.

Überschreiben Quelle Kopien
Wenn Sie lokal Änderungen an einer Datei vornehmen, erkennt makepp dies normalerweise und
Kompilieren Sie die Datei mit der lokalen Kopie und nicht mit der Repository-Kopie neu.

Wenn Sie ein Repository verwenden, um eine zentrale Codebasis zu verwalten, und Entwickler haben
Das Arbeiten an lokalen Kopien, die nur die von ihnen geänderten Dateien enthalten, ist ein Problem
kommt: Was ist, wenn ein Entwickler eine Datei aus seinem lokalen Build entfernen möchte, aber die
Enthält das Repository es noch? Wenn der Entwickler die lokale Kopie entfernt, wird makepp dies tun
Fügen Sie einfach die Kopie aus dem Repository ein und der Build wird wie bei der Datei fortgesetzt
existierte

Eine Möglichkeit (leider nicht für den Benutzer root) für dieses Problem besteht darin, die gewünschte Datei zu erstellen
Um nichts Unlesbares in den Build-Prozess einzubeziehen, gehen Sie wie folgt vor:

chmod a-rw auszuschließende Datei

Dadurch wird verhindert, dass makepp es aus dem Repository einbindet. Makepp beinhaltet auch
spezieller Code, damit unlesbare Dateien nicht mit Platzhaltern oder Musterregeln übereinstimmen.

Um zu verhindern, dass makepp ein ganzes Unterverzeichnis einbezieht, erstellen Sie auf ähnliche Weise ein lokales Verzeichnis
Verzeichnis mit demselben Namen, das jedoch nicht beschreibbar ist. Wenn Sie möchten, dass Makepp das ignoriert
Verzeichnis vollständig löschen und dann auch unlesbar machen. (Schreibgeschützte Verzeichnisse werden jedoch durchsucht
Ziele in ihnen werden normalerweise nicht gebaut.)

Die andere Möglichkeit, dies zu tun, besteht darin, makepp mit einer oder mehreren Ausschlussoptionen aufzurufen:

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

Nicht - Repositories für Dateien welche können. Veränderung!
Versuchen Sie nicht, ein Repository für eine Datei zu verwenden, die Teil Ihres Builds ist. Zum Beispiel du
Sie könnten versucht sein, Repositorys zu verwenden, um alle Ihre öffentlichen .h-Dateien im selben Verzeichnis abzulegen
Verzeichnis, etwa so:

# Makefile der obersten Ebene
Repository include=module1/include
Repository include=module2/include
Repository include=module3/include
Repository include=module4/include

Dies ist wahrscheinlich keine gute Idee, wenn für .h Dateien sind selbst Ausgaben von a
Programm (z. B. yacc oder ein anderes Programm, das C-Quellcode ausspuckt), weil makepp
geht davon aus, dass sich Dateien in Repositorys nie ändern. Wenn der Build benötigt wird include/xyz.h und
module2/include/xyz.h tatsächlich von einem Programm erstellt werden muss, wird makepp nicht wissen
um das Programm auszuführen. Es ist besser, eine Technik wie diese zu verwenden, um alles zu platzieren .h Dateien
in ein gemeinsames Include-Verzeichnis:

# module1/Makeppfile
../include/%.h : include/%.h
&cp $(Eingabe) $(Ausgabe)
# Sie könnten auch Folgendes tun (effizienter, aber problematischer unter Windows):
# &ln -r $(Eingabe) $(Ausgabe)

Makepp versucht möglicherweise immer noch, Dateien zu erstellen, die sich zufällig in einem Repository befinden, wenn Sie dazu aufgefordert werden
für sie direkt, aber es wird sie nicht aufbauen on Namen des lokalen Verzeichnisses. Das Ergebnis
Dies kann ziemlich verwirrend sein, da es zu einem symbolischen Repository-Link führen kann
Wird verwendet, während das Repository-Ziel veraltet ist, dieses Ziel jedoch möglicherweise später aktualisiert wird
im Bau. Sie können dies verhindern, indem Sie sicherstellen, dass die
Repository bezeichnet wird einzige über den Repository-Pfad oder indem Sie sicherstellen, dass dieser vorhanden ist
ist auch eine lokale Regel für alle generierten Repository-Dateien.

Eine andere Möglichkeit, das Neukompilieren identischer Dateien in verschiedenen Verzeichnissen zu vermeiden, ist die Verwendung von a
Build-Cache (siehe makepp_build_cache für Details). Ein Build-Cache verfügt nicht über das
Einschränkung, dass die Datei nicht verändert werden darf.

Verwenden Sie makepp_repositories online über die Dienste von onworks.net