Hallo, wir haben folgendes Problem: Wir würden gerne generelle Bibliotheken nicht jedesmal mit ins Projektverzeichnis sondern für jedes Projekt zugänglich machen. Einfach um bei Änderungen und Bugfixes nur eine Datei anfassen zu müssen und nicht jedes Projekt einzeln. Das Problem ist jetzt, dass die Bibliotheken teilweise durch Headerdateien gesteuert werden (in den Headerdateien sind defines für bedingte Compilierungen, array Größen und andere Projekt abhängige Dinge). Wie kann man es jetzt schaffen, dass die Bibliothek immer die z.B. settings.h aus dem aktuelle compilierten Projekt einbindet? Ich möchte also für jedes Projekt meine settings.h haben, die restlichen Bibliotheksdateien aber gemeinsam nutzen. zur Veranschaulichung sieht die Verzeichnisstruktur jetzt z.B. so aus: /lib/meine_lib_funktionen.c /projekte/mein_projekt1/projektdateien.* /projkete/mein_projekt1/settings.h /projekte/mein_projekt2/andere_projektdateien.* /projkete/mein_projekt2/settings.h die meine_lib_funktionen.c soll dann immer die "richtige" settings.h einbinden. Jemand eine Idee wie man sowas umsetzen kann? Vielen Dank schonmal Philipp PS: Entwickelt wird normalerweise im AVR-Studio
Phil schrieb: > Wie kann man es jetzt schaffen, dass die Bibliothek immer die z.B. > settings.h aus dem aktuelle compilierten Projekt einbindet? Die Frage ist etwas ungewöhnlich, denn eigentlich gibt es nur das umgekehrte Problem. Ein
1 | #include "settings.h" |
includiert immer die Datei aus dem jeweiligen Projektverzeichnis. Oliver
1. Wenn eine Lib halbwegs allgemeingültig ist, braucht sie keine projektspezifischen Sachen. 2. Braucht sie die, dann ist sie nicht allgemeingültig. Im ersten Fall sollte dein Problem nicht auftreten, im zweiten kommt mir irgendetwas unausgegoren vor. Insbesondere der Fall: eine Lib ist gebaut, danach ändert sich etwas an einer Headerdatei. Ist dann sichergestellt, daß ein Projekt nicht mit alter Lib, aber selbst den neuen Headern arbeitet?
@Oliver die ein "include.h" bindet doch die Datei ein die imselben Verzeichnis liegt wie die Datei die das include beinhaltet? @Klaus: Im diesem speziellen Fall geht es um eine USB Bibliothek. Ein großteil davon ist in ASM geschrieben und wird in C Projekte eingebunden. Und natürlich könnte man viele Parameter zur Laufzeit übergeben, aber schneller und sparsamer ist es auf jedenfall einfach ein paar defines zu ändern um die neue PID, VID usw. festzulegen und diese auch nicht immer aus dem RAM zu holen. Zudem beinhaltet diese Bibliothek die Unterstützung für zwei verschiedene Modi (verschiedene Treiber auf der Windows Seite) auch das lässt sich natürlich auch noch zur Laufzeit auswählen, aber wozu den Code mit in den Controller packen, wenn er nicht benötigt wird? Zudem machen zusätzliche Verzweigungen im Code das ganze nicht wirklich schneller bei der USB Kommunikation. Normalerweise würde ich dir ansosnten zustimmen. Dein angesprochenes Beispiel mit Änderungen an der Headerdatei stimmen zwar, aber ab dem Zeitpunkt ist eh eine intensive Kommunikation der beiden Entwickler erforderlich. Wenn der Lib Entwickler einfach nur ein paar interne Routinen optimiert hätte der Anwendungsentwickler beim nächsten compilieren alle Vorteile automatisch mit eingebaut. Viele Grüße Philipp
Hm, ich fürchte es geht um Windows. Mit Linux würde man das mit ein paar Links erschlagen, die in jedem Projektverzeichnis auftauchen und alle auf dieselbe Datei im Lib-Verzeichnis zeigen. Bei ntfs gibt es doch angeblich Links?
Ja, das ganze wird hauptsächlich unter Windows gemacht (AVR-Studio). Eine Lösung die Links verwendet wäre nur interessant, wenn diese auch SVN kompatibel ist. Symlinks wären wirklich mal ein Fortschritt bei Windows :)
Phil schrieb: > @Oliver die ein "include.h" bindet doch die Datei ein die imselben > Verzeichnis liegt wie die Datei die das include beinhaltet? Ja. Aber nicht nur da. Wenn es im aktuellen Verzeichnis keine passende Datei gibt, klappert der gcc seine Suchpfade ab. Und die lassen sich über die Option -I beliebig setzen. Wenn du also dem Compileraufruf (in diesem Beispiel aus dem Verzeichnis, in dem auch deine Projektquellen und die settings.h stehen) ein -I. mitgibst, sucht er als nächstes im Aufrufverzeichnis des Compilers. Oliver
Warum verrätst du nicht gleich, daß es um svn geht? Wenn dich die Platzverschwendung nnicht stört (Quelltext fällt auf heutigen Platten ja nicht besonders auf), dann gibt es vielleicht eine ganz andere Lösung. Nachdem je nach Projekt das Übersetzen der "Lib" ja anders aussieht, ist es ja offenbar gar keine Bibliothek im Sinne des Linkers, sondern in den einzelnen Projekten jeweils Quelltext, der dort mit kompiliert wird? Dann könntest du doch in jedem Projekt die Lib erneut auschecken in einem Unterverzeichnis des Projekts, also z.B. /projekte/mein_projekt1/projektdateien.* /projekte/mein_projekt1/settings.h /projekte/mein_projekt1//lib/meine_lib_funktionen.c /projekte/mein_projekt2/andere_projektdateien.* /projekte/mein_projekt2/settings.h /projekte/mein_projekt2//lib/meine_lib_funktionen.c In meine_lib_funktionen.c steht dann entweder ein #include "../settings.h" oder #include "settings.h". (Das hat dann auch den Vorteil, daß eine neue Version der meine_lib_funktionen.c erst in einem Projekt wirksam wird, wenn man explizit ein Update macht. Ansonsten kann es einem passieren, daß man fleißig testet, sich dann die meine_lib_funktionen.c ändert und die Tests damit hinfällig werden, ohne daß es jemand merkt.) Zumindest unter Linux würde das mit svn so funktionieren. Ich gehe davon aus, daß es unter Windows ebenso geht. Allerdings ist das nicht mit jeder Versionsverwaltung so; TFS zum Beispiel übergibt sich, wenn man auf einem Rechner etwas mehrfach auschecken will. D.h. man ist ggf. dann auf Dauer an svn gekettet, was ja nicht schlecht sein muß :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.