Salut tout le monde !

Je n'arrivais pas à comprendre la commande et quelle est sa différence par rapport à la commande install classique :

install(EXPORT <name>
  NAMESPACE <namespace>
  FILE <name>.cmake
  DESTINATION <dir>
  )

alors je suis allé voir dans le fichier qu'elle générait (parce que si j'ai bien compris cette commande sert à générer le fichier <name>.cmake dans un premier temps).

Et en gros à l'intérieur de ce fichier j'ai vu un script qui exécutait des commandes

add_library(myLib SHARED IMPORTED)

J'ai ensuite essayé dans un projet de comparer avec la commande add_library classique et la seule différence que j'ai repérée c'est qu'avec l'option IMPORTED la library n'était tout simplement pas générée. Quelle est l'intérêt de l'option IMPORTED dans ce cas ?

Merci d'avance !!!

Salut,

De manière générale, il y a une différence entre le développement d'une bibliothèque et son utilisation.

Car, lorsque tu veux développer ta bibliothèque, il va falloir ... la compiler; générer les fichiers objets (les fichiers qui contiennent le code binaire exécutable des fonctions), puis générer l'archive ou la dll (en fonction que tu as choisi de créer une bibliothèque statique ou dynamique) qui regroupera tout le code binaire pour le rendre disponible pour "autre chose".

Seulement, tu peux avoir deux raisons très différentes pour créer une (ou des) bibliothèques, même si le résultat final (une fois qu'elle(s) a (ont) été installée(s) ) est identique:

En effet, tu peux vouloir créer une (ou des bibliothèque(s) dans le cadre d'un projet bien particulier, pour limiter les dépendances entre les différentes parties d'un projet global.

Par exemple, si tu veux manipuler une base de données, une connexion internet, du son, des maths avancée et du graphisme 3D, tu as sans doute intérêt à créer une bibliothèque pour chacun de ces domaines particuliers, "simplement" parce que, lorsque tu manipule ta base de données, tu n'as -- a priori -- aucune raison d'avoir besoin du graphisme, des maths et de la connexion internet: chacun de ces domaines peut -- a priori -- être géré de manière totalement indépendante. Ce sera le rôle de l'application de "mettre ces domaines en commun" et de choisir "intelligemment" quand avoir recours à l'un ou à l'autre.

Par contre, tu peux aussi (cela arrive malgré tout régulièrement) vouloir développer une bibliothèque "seule" dans le cadre d'un projet. Dans ce cas, tu peux ne pas fournir d'application (hormis quelques exemples, peut-être), car le but de ton projet est -- vraiment -- de fournir un ensemble de fonctionnalités "bien précises" (par exemple, les composants d'un ECS, ou les fonctionnalités de calcul vectoriel et matriciel) dans le but bien avoué de ... les rendre disponibles pour d'autres projets avec lesquels tu n'as -- a priori -- absolument rien à voir.

Quoi qu'il en soit, une fois que la biliothèque aura été compilée, elle sera installée: les fichiers d'en-têtes seront sans doute copiés dans un sous dossier (au nom de la bibliothèque) du dossier include de ton système, et la bibliothèque en elle-même (le fichier .a ou .so sous linux, .lib ou .dll sous windows) sera quant à elle copiée dans le dossier lib de ton système.

Et cette installation va -- a priori -- te permettre d'utiliser la bibliothèque dans le cadre d'un projet qui ... n'a absolument rien à voir avec le projet d'origine.

Pour te donner un exemple et pour faire simple, c'est ce qui se passe lorsque tu installe boost ou Qt (ou bien d'autres) sur ton système: tu ne prends -- a priori -- aucune part dans le développement de ces bibliothèques, mais tu veux pouvoir les utiliser "facilement" dans le cadre de tes propres projets.

Et comme elles prennent "des plombes" à être compilées, tu appréciera sans doute de n'avoir pas à les compiler spécifiquement pour chaque projet qui les utilise. 

Ou bien, tu peux -- aussi -- décider d'utiliser une bilbiothèque "close sources" (une bibliothèque "commerciale", dont la société qui la produit ne fournit pas les sources), et ne simplement pas pouvoir ajouter les sources de la bibliiothèque à chacun des projets qui l'utilise pour l'intégrer à tes projets.

Quelle qu'en soit la raison (et tu te rends sans doute compte qu'elles sont nombreuses), il peut arriver que tu veuilles utiliser ce que l'on peut appeler une "bibliothèque externe" (une bibliothèque qui ne sera pas compilée dans le cadre de ton projet) pour développer ton projet. Il faut donc préciser à CMake que cette bibliothèque existe déjà (en lui fournissant les dossiers dans lesquels il trouvera les en-tête et les fichiers binaires) et ... qu'il n'y a pas besoin de la recompiler.

Toute cette explication n'a que pour objectif de te faire comprendre que, lorsque tu précise IMPORTED à CMake, il devra "se contenter" d'aller les fichiers d'en-tête et les fichiers binaires de la bibliothèque indiquée à l'endroit où ils se trouvent, et qu'il ne devra pas commencer à ... compiler cette bibliothèque (car cela a déjà été fait)

ThomasAirain a écrit:

Merci !

Bonjour,

Sujet résolu