Header Files aus Projekt Ordner in Lib Funktionen includen

[Phil (Gast)]

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

[Oliver (Gast)]

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

#include "settings.h"

includiert immer die Datei aus dem jeweiligen Projektverzeichnis.

Oliver

[Klaus W. (mfgkw)]

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?

[Phil (Gast)]

@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

[Klaus W. (mfgkw)]

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?

[Phil (Gast)]

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 :)

[Oliver (Gast)]

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

[Klaus W. (mfgkw)]

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ß :-)