Où placer les bibliothèques
La meilleure solution est d'utiliser le système de packaging de votre distribution Linux (apt-get , yum , ou similaire) pour installer des bibliothèques à partir de packages fournis par la distribution dans la mesure du possible.
Si les bibliothèques packagées de la distribution ne sont pas d'une version suffisamment récente, ou si vous avez besoin d'options de construction non standard, ou si vous avez besoin d'une bibliothèque que votre distribution ne fournit pas, vous pouvez la construire et l'installer vous-même. Vous avez deux options principales pour savoir où placer la bibliothèque :
/usr/local(bibliothèques sous/usr/local/lib, en-têtes sous/usr/local/include). Cela installe les bibliothèques à l'échelle du système et est probablement la solution la plus simple, puisque vous devriez alors pouvoir construire avec elles sans prendre d'étapes supplémentaires. N'installez PAS les bibliothèques directement sous/usr, car cela interférera avec le système d'empaquetage de votre distribution.- Sous le répertoire de votre projet, comme vous l'avez fait sous Windows. Cela présente les avantages de ne pas nécessiter d'accès root et de ne pas apporter de modifications à l'échelle du système, mais vous devrez mettre à jour les chemins d'inclusion et les chemins de bibliothèque de votre projet, et vous devrez placer tous les fichiers de bibliothèque partagés quelque part où l'éditeur de liens dynamique peut les trouver ( en utilisant
LD_LIBRARY_PATHould.so.conf- voir le lien pour plus de détails).
Fonctionnement des bibliothèques
Voir l'excellent HOWTO de la bibliothèque de programmation de David A. Wheeler. Je vous recommande de lire cela, puis de publier des questions spécifiques en tant que nouveaux sujets.
Comment distribuer votre programme
Traditionnellement, les programmes Unix/Linux n'incluent pas de copies de leurs dépendances. C'est plutôt à l'utilisateur final ou au développeur d'installer ces dépendances eux-mêmes. Cela peut nécessiter un "large README", comme vous l'avez dit, mais cela présente quelques avantages :
- Les bibliothèques de développement peuvent être installées, gérées et mises à jour via le gestionnaire de packages de la distribution, au lieu que chaque copie source ait son propre ensemble de bibliothèques à suivre.
- Il n'y a qu'une seule copie d'une bibliothèque donnée sur un système, donc il n'y a qu'un seul endroit qui doit être mis à jour si, par exemple, une faille de sécurité est découverte. (Par exemple, considérez le chaos qui a résulté lorsque zlib, une bibliothèque de compression très utilisée, s'est avérée avoir une faille de sécurité, de sorte que chaque application qui comprenait une version affectée devait être mise à jour.)
- Si votre programme est assez populaire (et qu'il est open source ou au moins disponible gratuitement), alors les mainteneurs de packages pour diverses distributions Linux voudront peut-être l'empaqueter et l'inclure dans leur distribution. Les mainteneurs de paquets vraiment n'aime pas les bibliothèques groupées. Voir, par exemple, la page de Fedora sur le sujet.
Si vous distribuez votre programme aux utilisateurs finaux, vous pouvez envisager d'offrir un package (.dpkg ou .rpm ) qu'ils pouvaient simplement télécharger et installer sans avoir à utiliser la source. Idéalement, du point de vue de l'utilisateur final, le package serait ajouté aux référentiels des distributions (s'il est open source ou au moins disponible gratuitement) afin que les utilisateurs puissent le télécharger à l'aide de leurs gestionnaires de packages (apt-get ou yum ). Tout cela peut devenir compliqué, en raison du grand nombre de distributions Linux, mais un .dpkg compatible Debian/Ubuntu et un .rpm compatible Red Hat/CentOS/Fedora devrait couvrir un bon pourcentage d'utilisateurs finaux. Construire des packages n'est pas trop difficile et il existe de bons tutoriels en ligne.
pour la première partie de votre question concernant Windows :il n'y a pas de véritable place standard pour les bibliothèques/en-têtes sur Windows, donc la solution la plus simple est :créez la vôtre. Fournissez simplement un seul lib/ et include/ sur votre système et faites en sorte que tous vos projets l'utilisent (en définissant le chemin dans un fichier cmake que vous incluez partout). Mettez-y toutes les bibliothèques tierces, par exemple :
vos projets :
d:/projects/projectA
d:/projects/projectB
trucs tiers :
d:/api/lib/lua.lib
d:/api/include/lua/....
(vous pouvez même utiliser des liens symboliques appelés "jonctions de répertoires" si vous avez une version différente)
et le fichier cmake correspondant :
include_directories( d:/api/include )
link_directories( d:/api/lib )