Wie organisiere ich meinen C-Projektcode und seine externen Bibliotheken am besten?[geschlossen]

Question

Ich starte ein neues C-Projekt, das größtenteils OSS-basiert ist.Es wird auch auf SourceForge verfügbar sein, und ich möchte diese Gelegenheit nutzen, um etablierte Best Practices für die Organisation dieser Art von Code kennenzulernen.Ich verwende Bibliotheken wie libcurl und libz und kompiliere sie mit MinGW und MSYS.

Ich werde Kopien der Quelle aller Bibliotheken verteilen, die ich in meinem Projekt verwende, damit Leute, die die Quelle herunterladen, nicht nach Abhängigkeiten suchen müssen.Wie soll ich das Verzeichnis nennen, in dem ich die Bibliotheken speichere?Bisher schwanke ich zwischen:

• lib, weil es Bibliotheken sind.Allerdings hat „lib“ in der UNIX-Welt eine andere Konnotation.
• src, da es sich um Quelldateien handelt.
• Dritter, weil ich es nicht geschrieben habe.

Und wohin soll ich diese Bibliotheken kompilieren?Soll ich sie einfach konfigurieren und im Systemstammverzeichnis installieren, oder sollte ich ein Verzeichnis einrichten, in das alle Bibliotheken kompiliert und von dort aus verlinkt werden sollen?Offensichtlich wird dies Auswirkungen auf mein Makefile haben.

Wie soll ich dabei vorgehen?Gibt es etablierte Konventionen, denen ich folgen sollte?Sind sie irgendwo aufgeschrieben?

Answer 1

Erstens würde ich externe Bibliotheken verwenden vendor, aber das ist nur eine Präferenz.

Zweitens halte ich die Installation nicht für eine gute Idee andere Bibliotheken in einem Systemstammverzeichnis, ohne Wissen des Benutzers.Vor allem, weil dies zu Konflikten mit später installierten Versionen dieser Bibliotheken führt.Daher denke ich, dass der beste Ort für diese Bibliotheken im selben Verzeichnis wie Ihre Anwendung wäre.

Sie können diese Bibliotheken auch statisch in Ihr Programm kompilieren.

Answer 2

Bei einem früheren Job bestand der Standard darin, sie in einem Verzeichnis namens 3rdparty zu installieren und die Bibliotheken direkt dort zu erstellen (in 3rdparty/LIBNAME/Debug usw.).

Answer 3

Wir verwenden etwas mit dem Suffix _ext oder _EXT (z. B. MyProject_EXT), um anzuzeigen, dass es außerhalb unseres Projekts liegt, um den Quellcode externer Pakete zu speichern, mit denen wir verlinken.

Ich stimme Peter zu.Die externen Bibliotheken sollten nicht in das Systemstammverzeichnis integriert werden, da sie zu Konflikten führen können.Ich würde sie in ihrem Verzeichnis erstellen und sie dann in einem /lib-Verzeichnis (oder vielleicht /extlib) installieren, das für Ihre Anwendung eindeutig ist, und dort eine Verknüpfung zu ihnen herstellen.

Answer 4

Bitte nicht Versenden Sie Quellen von Drittanbietern mit Ihrem Code, entweder in der Quelle oder statisch in die Binärdateien verknüpft oder auf andere Weise.Dies stört nur andere Kopien derselben und wird nicht aktualisiert, wenn die Bibliothek repariert werden muss.Informieren Sie den Benutzer über die Anforderungen (und halten Sie sich über API-Änderungen in der Bibliothek auf dem Laufenden!).Ein selbstkompilierender Benutzer stellt sicher, dass er die Abhängigkeiten erhält, eine Distribution stellt sicher, dass Ihr Paket mit der Version funktioniert, die sie ausliefern.