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

Question

Ich beginne ein neues C-Projekt, das weitgehend OSS-basiert ist. Es wird auch bei SourceForge sein, und ich möchte diese Gelegenheit nutzen, bewährte Methoden zum Organisieren dieser Art von Code zu erlernen. Ich benutze Bibliotheken wie libcurl und libz und ich kompiliere es mit MinGW und MSYS.

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

• lib, weil sie Bibliotheken sind. "Lib" hat jedoch eine andere Bedeutung in der UNIX-Welt.
• src, weil sie Quelldateien sind.
• 3rd Party, weil ich es nicht geschrieben habe.

Und wo soll ich diese Bibliotheken kompilieren? Sollte ich sie einfach im System-Root konfigurieren und installieren, oder sollte ich ein Verzeichnis einrichten, in dem alle Bibliotheken kompilieren und von dort verlinken sollen? Offensichtlich wird dies Auswirkungen auf mein Makefile haben.

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

Answer 1

Zunächst für externe Bibliotheken würde ich vendor verwenden, aber das ist nur eine Präferenz.

Zweitens, ich glaube nicht, dass es eine gute Idee ist, andere Bibliotheken in einem Systemstamm zu installieren, ohne das Wissen der Benutzer. Am wichtigsten ist, dass dies zu später installierten Versionen dieser Bibliotheken führen wird. Ich denke also, der beste Platz für diese Bibliotheken wäre im selben Verzeichnis wie Ihre Anwendung.

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

Answer 2

Bei einem früheren Job war der Standard, 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 der _EXT oder _EXT Suffix (das heißt MyProject_EXT), um anzuzeigen, dass es zu unserem Projekt extern ist, den Quellcode von externen Paketen zu speichern, die wir gegen verknüpfen.

Ich stimme mit Peter überein. Die externen Bibliotheken sollten nicht in das Systemstammverzeichnis integriert werden, da dies zu Konflikten führen kann. Ich würde sie in ihrem Verzeichnis erstellen und sie dann in ein/lib-Verzeichnis (oder vielleicht/extlib) installieren, das einzigartig für Ihre Anwendung ist und dort verlinkt.

Answer 4

Bitte nicht versenden Quellen von Drittanbietern mit Ihrem Code, entweder in der Quelle oder statisch in die Binärdateien oder auf andere Weise verknüpft. Das stört nur andere Kopien desselben und wird nicht aktualisiert, wenn die Bibliothek korrigiert werden muss. Teilen Sie dem Benutzer mit, was die Anforderungen sind (und halten Sie mit den API-Änderungen in der Bibliothek Schritt!). Ein selbst kompilierender Benutzer stellt sicher, dass die Abhängigkeiten erhalten werden. Eine Distribution stellt sicher, dass das Paket mit der Version funktioniert, die es liefert.