Dateien einbeziehen - Gemeinsame Quelle und doppelte Namen

Question

Ich habe eine Situation, in der ich zwei Bibliotheken verwende, die doppelte Header-Dateinamen haben. Zum Beispiel timer.h ist in beiden Bibliotheken vorhanden. Ich denke, die normale Lösung für dieses Problem wäre, das Verzeichnis im Include explizit anzugeben, wie #include <dir1/timer.h> o #include <dir2/timer.h> damit der Compiler einen Anhaltspunkt hat, was ich angebe. Mein Problem ist jedoch, dass eine der Bibliotheken, die ich verwende, nicht in einem Unterverzeichnis meines Projekts liegt. Sie befindet sich irgendwo anders auf einer höheren Ebene. Das heißt ...

• Wurzel
  • Bibliothek1
  • Projekte
    • ProjektOrdner
      • Bibliothek2

Dies geschah, damit mehrere Projekte auf Library1 verweisen können. Damals schien das eine gute Idee zu sein. Jetzt jedoch, wo ich den Namenskonflikt von Library2 habe, entstehen Probleme. Ein weiteres wichtiges Detail ist, dass ich oft zwei verschiedene Workstations verwende. Der absolute Speicherort von Library1 auf diesen Workstations ist nicht derselbe, und auch der relative Speicherort (in Bezug auf den Projektordner) ist nicht derselbe auf beiden. Bisher habe ich die beiden absoluten Speicherorte in den Suchpfad des Präprozessors aufgenommen.

Wie auch immer, ich wäre für jeden Ratschlag dankbar, den Sie mir geben können.

Answer 1

Sie sind auf dem richtigen Weg mit "dir1/timer.h" y "dir2/timer.h" . Aber anstatt es als dir betrachten Sie es als "project1/timer.h" . In Ihrem Makefile müssen Sie nun den Speicherort von project1 hinzugefügt zu Ihrem include Suchpfad, wenn er sich nicht an einem gemeinsamen Ort befindet.

Sie sollten keine relativen Pfade in Ihrem Code haben (keine ../file.h ). Sie sollten relativ zum Basisverzeichnis ihres Projekts sein (z. B. #include <sys/socket.h> o #include <linux/sched.h> ). Dann liegt es an deinem Makefile, sie zu finden (diese beiden Beispiele sind im Standardsuchpfad, also werden sie funktionieren). Für Ihren Fall können Sie -I<path to project directory> und dann #include "other_project/library.h" .

Answer 2

Ich würde es vorziehen, eine Kopie einer bestimmten Version der externen Bibliothek in mein Projekt einzubinden und bei Bedarf auf eine neuere Version zu aktualisieren (aber nicht die externe Bibliothek aus dem Projekt heraus zu ändern). Wenn Sie nur auf die aktuelle (sich ändernde) Version verweisen, die von allen verwendet wird, kann sich das Verhalten Ihres Projekts ändern, ohne dass der Code geändert wird. Eine neue Version Ihres Projekts müsste sich auch auf die Version der Bibliothek beziehen, die Sie zu diesem Zeitpunkt verwenden, um vollständig zu sein.

Wenn Sie es so gemacht haben, sind die relativen Pfade immer die gleichen (z.B. "../ExternalLib"), wenn Sie diesen Ansatz verwenden möchten. Oder Sie können tun, was Dave vorschlägt.