Où placer des bibliothèques tierces pour configurer un environnement de développement Linux C ++?
Je ne suis pas nouveau en C++ bien que je sois nouveau sous Linux. J'utilise CMake pour précompiler un moteur de jeu multiplateforme avec des composants tiers, mais j'ai beaucoup de doutes sur l'utilisation des bibliothèques. Ma question est de savoir comment travailler avec des bibliothèques tierces et où les mettre. Apt installe les bibliothèques à leur place officielle (/ usr/local,/usr/lib/..) mais je développe sous Windows en utilisant des bibliothèques locales qui se trouvent dans un dossier dans mon répertoire de projet.
De plus, j'ai besoin d'un bon tutoriel pour connaître les règles de fonctionnement des bibliothèques. Par exemple: lors de la compilation de mon projet, luabind demande liblua.s0.1, mais AFAIK il n'y a aucun moyen de générer cette bibliothèque avec la source fournie par Lua (au moins faire make, make install).
Je sais, cette question est floue mais je n'ai pas assez d'expérience pour être plus concis.
Mise à jour: Après avoir lu certaines réponses, une question plus concise est la suivante. Si j'installe toutes les bibliothèques tierces, comment puis-je distribuer mon programme? Comment gérer les dépendances sans utiliser un fichier Lisezmoi volumineux?
Où mettre les bibliothèques
La meilleure solution consiste à 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 empaquetées de la distribution ne sont pas d'une version assez 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 disposez de deux options principales pour l'emplacement de 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, car vous devriez alors pouvoir les construire sans prendre de mesures supplémentaires. N'installez PAS de bibliothèques directement sous/usr, car cela va interférer avec le système d'emballage de votre distribution.- Sous votre répertoire de projet, comme vous l'avez fait sous Windows. Cela a l'avantage 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ù le é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 David A. Wheeler Programming Library HOWTO . Je recommanderais de lire cela, puis de poster 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. Il appartient plutôt à l'utilisateur final ou au développeur d'installer ces dépendances elles-mêmes. Cela peut nécessiter un "grand fichier README", comme vous l'avez dit, mais il 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 trouvée. (Par exemple, considérons le chaos qui s'est produit lorsque zlib , une bibliothèque de compression très largement utilisée, s'est avérée avoir un défaut de sécurité , donc chaque application qui comprenait une version affectée devait à mettre à jour.)
- Si votre programme est assez populaire (et est open source ou au moins disponible gratuitement), les responsables de package pour diverses distributions Linux peuvent vouloir le packager et l'inclure dans leur distribution. Les responsables de paquets vraiment n'aiment pas les bibliothèques groupées. Voir, par exemple, page de Fedora sur le sujet .
Si vous distribuez votre programme à des utilisateurs finaux, vous pouvez envisager de proposer 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 librement disponible) 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 d'une compatibilité Debian/Ubuntu .dpkg et compatible avec Red Hat/CentOS/Fedora .rpm devrait couvrir un bon pourcentage d'utilisateurs finaux. La construction de packages n'est pas trop difficile, et il existe de bons howtos 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 simple est: créez la vôtre. Fournissez simplement une seule 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 toutes les bibliothèques tierces dedans, par exemple:
tes 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 alias "jonctions de répertoire" si vous avez une version différente)
et le fichier cmake correspondant:
include_directories( d:/api/include )
link_directories( d:/api/lib )
D'accord, c'est donc l'une des questions fondamentales et même si je ne suis peut-être pas très clair à ce sujet, voici:
- Lors de la construction d'un projet, votre compilateur devra trouver les fichiers d'en-tête des bibliothèques. Les en-têtes doivent être dans le chemin d'inclusion.
- une fois la compilation terminée, l'éditeur de liens recherchera les fichiers binaires de la bibliothèque (files.so ou quelque chose du genre). Ceux-ci doivent être dans le chemin de la bibliothèque.
Voilà l'essentiel.
Si vous avez des bibliothèques spécifiques, vous pouvez les ajouter à votre propre projet lib/ et include/ répertoires et ajoutez-les respectivement au chemin d'inclusion et au chemin de bibliothèque.
L'ajout de ces répertoires à ces chemins peut se faire de plusieurs manières, selon la façon dont vous générez le projet. Je suis sûr qu'il y a quelque chose appelé LD_PATH impliqué dans tout cela ... Mais je ne connais pas vraiment les détails impliqués avec CMake.
Un peu de recherche sur Google peut vous aider à faire ce qui précède avec CMake.
J'espère que cela pourra aider,
jrh
Si vous installez les bibliothèques avec un gestionnaire de paquets, elles se retrouveront probablement toutes au bon endroit. Sinon, vous pouvez demander au compilateur de rechercher le en fournissant le chemin de recherche supplémentaire en utilisant le -L <path> drapeau. Vous devriez pouvoir passer ce drapeau supplémentaire à CMake.
Soit dit en passant, le -I <path> peut être utilisé pour ajouter un répertoire supplémentaire pour rechercher des fichiers d'inclusion.