Discussion :

[DeLaFonk]

Salut les gens,

J'aurais une question pour ceux qui maîtrisent un peu les bibliothèques. Je suis dans le cas où je dois compiler des DLLs mais j'ai deux DLLs qui s'invoquent l'une l'autre. Forcément, ça pose problème.
Ma première question est la suivante, sans passer par des .def et sans faire de compilations successives, du genre je compile ma première DLL, je compile la deuxième qui fait référence à la première et je recompile la première en incluant une référence vers la deuxième etc.. y aurait-il une façon de procéder un peu plus clean ?

Autre question, ma première DLL fait donc référence à la deuxième (par un #include). Si je ne spécifie pas au compilateur la bibliothèque à fournir, forcément, ça va gueuler au moment de linker (undefined reference gnagnagna..) y aurait-il un moyen de compiler malgré tout ma première DLL indépendamment des autres, en lui spécifiant que les autres symboles seront définis plus tard, à la manière des "extern" utilisés en C, qui permettent de compiler mais qui supposent plus tard qu'une implémentation soit dispo dans le code compilé ?

Merci bien

(..sur Win32/Mingw32)

[koala01]

Salut,

Si tu as deux dll qui se trouvent dans une situation de référence circulaire (la première faisant référence à la deuxième et réciproquement), il y a de grandes chances que tu te trouves soit dans le cas d'un énorme problème de conception (non respect du Depedancy inversion Principle, avec, au passage, création éventuelle d'un troisième dll ) soit face à un cas où tu as induement tenté de séparer en deux dll ce qui n'aurait jamais du l'être et rester dans un dll unique

Il n'y a, malheureusement aucun moyen de forcer la réussite de la compilation dans le cas de dll ayant des dépendances circulaires.

Soit tu décides de regrouper les deux dlls en une seule, soit il faudra revoir l'ensemble de la conception de manière à casser cette circularité (il y a surement "quelque chose" qui pourrait servir de base à une dll qui serait utilisée par les deux que tu essayes de générer et qui sera "indépendant" de chacune )

Pour rappel, il est SOLID est un acronyme qui reprend les cinq "piliers de base" de la programmation OO...

Réfléchis un peu de manière globale pour voir si tu respecte ces différents principes sur l'ensemble de ton projet, et surtout, entre tes différents modules / dll

Tu risques fort d'être surpris

[DeLaFonk]

Salut koala01 et merci de ta réponse.

Oui, y a pas à tortiller de toute manière, dès qu'il y a une référence circulaire, c'est forcément un souci de design. Ça correspond à ma première question..

Ma deuxième question est un peu plus importante (le coup de l'inter-dépendance, je peux résoudre ça aisément, mais ça n'était pas l'objet principal de mon post). Pour revenir à ma deuxième question, j'étais quasi persuadé d'avoir vu quelque-part un moyen de mettre en 'extern' des symboles ou des variables utilisés par une DLL pour permettre sa compilation..
Et je me rends compte qu'en écrivant ceci, je me réponds en partie à moi-même.. A savoir, qu'il sera éventuellement possible de compiler mais pas de linker pour aboutir à la DLL.. Ce qui pose le problème de l'ordre de compilation, du coup, si une DLL dépend d'une autre pour le link, il faudra respecter un ordre de compilation, non ??

[Médinoc]

Oui, mais c'est à ça que sert la gestion de dépendances (dans un makefile, ou une solution Visual Studio, etc.)