Quelle est la meilleure façon d’organiser le code de mon projet C et ses bibliothèques externes ?[fermé]

Question

Je démarre un nouveau projet C, largement basé sur OSS.Ce sera également sur SourceForge, et j'aimerais profiter de cette opportunité pour apprendre les meilleures pratiques établies pour organiser ce type de code.J'utilise des bibliothèques comme libcurl et libz, et je vais le compiler en utilisant MinGW et MSYS.

Je distribuerai des copies des sources de toutes les bibliothèques que j'utilise avec mon projet, afin que les personnes téléchargeant les sources n'aient pas à chercher des dépendances.Comment dois-je appeler le répertoire dans lequel je stocke les bibliothèques ?Pour l'instant, j'hésite entre :

• lib, car ce sont des bibliothèques.Cependant, « lib » a une connotation différente dans le monde UNIX.
• src, car ce sont des fichiers sources.
• Tiers, parce que je ne l'ai pas écrit.

Et où dois-je compiler ces bibliothèques ?Dois-je simplement les configurer et les installer à la racine du système, ou dois-je configurer un répertoire dans lequel toutes les bibliothèques doivent être compilées et liées à partir de là ?Évidemment, cela aura des conséquences sur mon Makefile.

Comment dois-je procéder?Y a-t-il des conventions établies que je dois suivre ?Sont-ils écrits quelque part ?

Answer 1

Premièrement, pour les bibliothèques externes, j'utiliserais vendor, mais ce n'est qu'une préférence.

Deuxièmement, je ne pense pas que ce soit une bonne idée d'installer autre bibliothèques dans une racine système, à l'insu des utilisateurs.Plus important encore, car cela entrera en conflit avec les versions installées ultérieures de ces bibliothèques.Je pense donc que le meilleur endroit pour ces bibliothèques serait dans le même répertoire que votre application.

Vous pouvez également compiler statiquement ces bibliothèques dans votre programme.

Answer 2

Lors d'un travail précédent, la norme était de les installer dans un répertoire nommé 3rdparty et de créer les bibliothèques ici (dans 3rdparty/LIBNAME/Debug, etc.).

Answer 3

Nous utilisons quelque chose avec le suffixe _ext ou _EXT (c'est-à-dire MyProject_EXT) pour signifier qu'il est externe à notre projet pour stocker le code source des packages externes avec lesquels nous établissons un lien.

Je suis d'accord avec Pierre.Les bibliothèques externes ne doivent pas être intégrées à la racine du système car elles pourraient provoquer des conflits.Je les construirais dans leur répertoire, puis les installerais dans un répertoire /lib (ou peut-être /extlib) unique à votre application et créerais un lien vers eux.

Answer 4

S'il te plaît ne le faites pas expédiez des sources tierces avec votre code, soit dans la source, soit liées statiquement aux binaires, ou de toute autre manière.Cela interférera simplement avec d'autres copies de celui-ci et ne sera pas mis à jour lorsque la bibliothèque nécessitera une réparation.Dites à l'utilisateur quelles sont les exigences (et suivez les modifications de l'API dans la bibliothèque !).Un utilisateur auto-compilant s'assurera d'obtenir les dépendances, une distribution s'assurera que votre package fonctionne avec la version qu'il livre.