Compilation dll dans l'executable

Version imprimable

10/09/2010, 19h18
Astraya

Compilation dll dans l'executable

Bonjour,

Je cherche actuellement à intégrer une DLL simple dans un projet. Ce projet étant très modulaire, je viendrais à avoir de nombreuses DLL pour augmenter la vitesse de compilation. Je n'aimerais pas avoir mon exe et 20 DLL à côté.

Je sais que d'habitude on ne veux pas faire ça... mais il faut savoir que certaines machines ne peuvent pas utiliser les DLL ( PS, XBOX, Wii...)
Je cherche donc une astuce :p

- Savez vous intégrer une DLL dans votre exécutable à la compilation de celui-ci?

- Est-ce possible possible de les mettre dans un fichier compressé, pour les charger avant de les utiliser?

- Comment dire à l'exe d'aller chercher la DLL autre part que dans son dossier courant?

Merci :)
11/09/2010, 15h38
Astraya

Après quelques petites recherche, je vais changer ma façon de procéder.
Je vais donc développer en dynamique pour les tests pour la mettre en statique pour la release.

Je ne connais malheureusement que très peu l'utilisation des librairies.
Je n'ai pas trouvé de tutoriel sur les librairies C++ dynamique et statique.

Connaissez vous des liens ?

Peut on facilement changer la configuration d'un projet dll sous visual pour la mettre en statique?

merci :)

Edit : je viens de trouver ça dans la FAQ Visual mais ça ne parle que des dynamique... un truc sur les statiques? merci

Je suis arrivé à un moyen de faire simple.
bibliothèques dynamiques pour les tests et bibliothèques dynamiques pour la release.

J'ai donc réalisé une simple macro dans un fichier .h.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 //Used "#define LIB" to compile as static library (.lib) #ifdef LIB #define ARME_API #else //Used "#define DLL" to compile as dynamic library (.lib + .dll) #ifdef DLL // Compilation, change it in terms of project name #define DLL_API __declspec(dllexport) #else //Utilisation #define DLL_API __declspec(dllimport) #endif #endif
Je l'inclue dans tout .h exportable. Je change le type de configuration en dynamque ou statique dans Visual Studio.
Code:

1 2 3 4 5 6 7 //compilera en dynamique #define DLL #include "BuildLib.h" //ou compilera en static #define LIB #include "BuildLib.h"
Et voila.
Si certaines personnes ont des critiques ou des améliorations ou solutions alternative.. je suis partant.

Ce petit truc me permet en release de ne pas fournir les dlls à coté et en dans la phase de développement de ne pas avoir à rebuild le projet final.

13/09/2010, 11h56
bacelar

Vous n'utilisez pas les conventions standards de VS.
Les constantes de compilations LIB et DLL sont déjà utilisés pour la distinction des C-Runtime.

Je ne vois pas l'intérêt d'utiliser des dll tout en voulant supprimer deux de leurs principaux intérêts, le partage par plusieurs programmes, leur mise à jour sans modification/recompilation du programme client.

Si le but est d'avoir le choix entre une LIB ou une dll, une simple constante de compilation suffit (mais n'utilisez pas celles déjà standardisées) et les contraintes pour la conception correcte d'une API d'une Dll n'ont rien à voir avec celle d'une librairie statiques.
13/09/2010, 12h07
Astraya

Citation:

Vous n'utilisez pas les conventions standards de VS.

Je ne les connais pas... :aie:

Citation:

Je ne vois pas l'intérêt d'utiliser des dll tout en voulant supprimer deux de leurs principaux intérêts, le partage par plusieurs programmes, leur mise à jour sans modification/recompilation du programme client.

Je ne les supprimes pas. Je garde l'intérêt de la dll lors de mon développement. Lors du déploiement, à la compilation de la release, le programme ne doit plus avoir de dll car le support ne les acceptes tout simplement pas ( ce n'est pas pour du PC ).

Citation:

Si le but est d'avoir le choix entre une LIB ou une dll, une simple constante de compilation suffit

Laquel s'il vous plais? :)

Merci

EDIT : Les constantes ne seraient-elles pas plutôt _LIB et DLL_EXPORTS...?
13/09/2010, 12h24
jouana

Bonjour,

C'est pour de l'embarquer que vous développé ou pour une application informatique.

Parce que les librairies dynamiques sous unix-like(linux, bsd, mac) existent ce sont des .so les dll c'est pour windows.

Après je ne voit pas pourquoi vous développez en dynamique pour après faire du static cela n'a rien a voir :/

Les libs statiques sont compiler avec l'exe donc exe plus lourd les dynamiques sont pré-compilé et le bout de code est rattaché a l’exécutable pendant l’exécution.

Après si c'est pour une API on rentre dans un système de module donc c'est mieux quand c'est chargé a chaud ou au démarrage lancement de l'exe sans avoir a le re-compilé comme l'a dit bacelar.

Et des vestige de debug dans une release sa pu tu alourdit ton application et te prend la tête pour rien :/
13/09/2010, 12h33
Astraya

Bonjour jouana,

Il s'agit d'embarqué sur console. Donc pas de win32, pas linux, pas de dll ni de so... Mais une architecture grosse à temps de compilation important ( sur mon ordinateur 2h30 environ pour les projets actuelles).
Je ne peux pas me permettre de garder compiler a chaque fois mes librairies statiques avec le programme. Mais je ne dois pas avoir de dll au final... même si il est plus lourds... ( ce qui pèse ce sont les ressources pas forcement l'exe dans mes applications )

Citation:

Et des vestige de debug dans une release sa pu tu alourdit ton application et te prend la tête pour rien :/

Je debug en release avec les symboles, je les retirent pour la version final.
13/09/2010, 12h38
Astraya

Je rappels qu'il s'agit d'une solution que j'exploite et qui marche jusqu'à présent. Si il existe d'autres techniques, façon de faire pour moduler le code d'une façon similaire... je suis preneur ;)
13/09/2010, 14h33
bretus

Bonjour,

Pour les conventions, ce n'est pas ceci que vous cherchez par hasard?
http://msdn.microsoft.com/fr-fr/libr...8VS.71%29.aspx

J'ai du mal à voir ce que vous voulez au juste :

Citation:

Ce projet étant très modulaire, je viendrais à avoir de nombreuses DLL pour augmenter la vitesse de compilation. Je n'aimerais pas avoir mon exe et 20 DLL à côté.

S'il s'agit seulement de ne pas compiler l'intégralité du projet à chaque modification, il vous suffit de créer plusieurs projets, de compiler en bibliothèques statiques (.lib seul) et de lier ces .lib en ne passant pas par la case "dépendance" mais par la case "option du projet/éditeur de lien/dépendance supplémentaire" (comme pour une bibliothèque externe). Ca me semble d'ailleurs pas plus mal pour gérer les versions...

Ce que vous pouvez être amené à faire, c'est switcher la compilation des DLL et de bibliothèques statiques en jouant sur des #define pour que les export/import soit désactiver lors de la compilation des bibliothèques statiques. Voir pour le principe à l'adresse suivante http://www.codeguru.com/cpp/cpp/cpp_...icle.php/c9855
13/09/2010, 14h38
bacelar

Citation:

Citation:

une simple constante de compilation suffit

Oups. Pas une "constante de compilation" mais une configuration de compilation supplémentaire.
Si vous ne modifiez pas les sources des librairies, pourquoi les recompiler ?
Si vous les modifiez, la compilation d'une dll est plus longue que celle d'une librairie statique du à l'édition de lien.

Avoir un temps de compilation aussi long pour des librairies statiques est souvent le symptôme de référence circulaire entre librairie, chose à combattre au plus vite.

Le passage par les dll demande un refactoring des API qui risque d'être très couteux s'il est fait correctement.

Le passage par une dll en Debug/développement est un pis-aller à un problème bien plus concret qu'il faut comprendre avant de vous embarqué dans une galère.
13/09/2010, 14h45
jouana

Tu peut faire des .o (obj) et comme sa quand il n y a pas de modif sur le .o il ne se re-compil pas tu passe par le linkage des .o :)
13/09/2010, 16h50
Astraya

Citation:

S'il s'agit seulement de ne pas compiler l'intégralité du projet à chaque modification, il vous suffit de créer plusieurs projets, de compiler en bibliothèques statiques (.lib seul) et de lier ces .lib en ne passant pas par la case "dépendance" mais par la case "option du projet/éditeur de lien/dépendance supplémentaire" (comme pour une bibliothèque externe). Ca me semble d'ailleurs pas plus mal pour gérer les versions...

C'est ce que je fais. Mais donc vous dites que si je link disons 3 librairies statiques et que j'en modifie une. Lors de la compilation du projet global, il ne va que compiler avec la lib qui à été modifier depuis ça dernière compilation et ne vas pas perdre de temps avec celle qui n'ont pas été modifié?

Citation:

Ce que vous pouvez être amené à faire, c'est switcher la compilation des DLL et de bibliothèques statiques en jouant sur des #define pour que les export/import soit désactiver lors de la compilation des bibliothèques statiques. Voir pour le principe à l'adresse suivante http://www.codeguru.com/cpp/cpp/cpp_...icle.php/c9855

C'est exactement ce que j'ai fait, à une chose prêt, c'est que je vérifie si je demande une lib statique ou dynamique, avec un #define avant l'inclusion de mon .h contenant le jeu de #define __declspec(..). Il me permet en statique de supprimer les __declspec(..) et en dynamique de les garder.

Citation:

Si vous ne modifiez pas les sources des librairies, pourquoi les recompiler ?

Alors à ça je demande: la modification d'une librairie statique me demandera de recompiler le projet l'utilisant, mais si ce projet est lié à d'autres libraires statiques, qui elles n'ont pas été modifier.
Que fera le compilateur?
Il les ignorera et utilisera directement la dernière version déjà compiler?
ou les recompilera-t-il tous sans exception?

Merci
13/09/2010, 16h59
jouana

Ba cela dépend de toi et de ta manière de compiler.
Si tu compile juste le projet bah rien d'autre n'est re-compilé.
Mais si tu re-compile la solution il va compiler tout les projets.

Si c'est via Makefile c'est la même chose si tu dit a t'on Makefile de compiler les libs + l'exe bah il va tous re-compiler si tu passe par les .o tu limite la re-compilation juste au fichier modifier qui vont remplacer les .o (fichier pré-compiler) ensuite il va les linker pour refaire un nouvel exe.

Donc si tu n'efface pas les .o et que tu ne re-compile pas toutes tes libs bah tu va gagner du temps a la compilation de ton executable
13/09/2010, 17h05
Astraya

Pour le moment j'ai une solution avec 3 projets ( pour les tester tout ça ):
1- Ma librairie statique c++
2- Mon projet C++ utilisant ma dll
3- Mon projet C# utilisant aussi ma dll ( pas encore tester )

Donc imaginons que je rajoute un autre projet pour une autre librairie statique.
- je compile le projet C++
- je modifie la librairie 1
- je recompile le projet C++

Avec ses 3 étapes, il ne recompilera pas la librairie 2 qui n'a pas été modifié et donc agiras comme si il n'y avait que 1 librairie à compiler au final? Mais l'édition de lien, il devra les refaire avec les 2 libraires?
13/09/2010, 17h07
bacelar

OUI.
13/09/2010, 17h10
jouana

En faite tu as la solution et les projets dans la solution.
donc si tu compile un projet tu ne compile pas les autres.
Mais si tu compile la solution tu compile tous
13/09/2010, 17h18
Astraya

Ok très bien je vois donc plus clair. Malheureusement l'édition des liens sera aussi longue mais au moins la compilation sera plus rapide.

Je vous remercie.
15/09/2010, 19h13
screetch
j'ai eu a peu près le même problème pour mon projet. J'ai résolu le problème à la fois dans l'outil de build (qui sait comment construire les plugins et comment les intégrer au progamme) et dans le code source, pour que tout soit transparent du côté de l'utilisation de plugin.

J'ai une classe Plugin, template, comme suit:
Code:

1 2 3 4 5 6 7 template< typename Interface > class Plugin { Plugin(const std::string& name); ~Plugin(); Interface* operator->(); };
que l'on appelle ainsi:

Code:

Plugin<IRenderer> renderer ("renderOpenGL");

l'implémentation du plugin va déterminer s'il s'agit juste d'instancier une classe compilée statiquement, ou charger une DLL et appeler une fonction.
Dans le plugin lui même, une macro se charge de générer le code qui va bien, dépendant de la plate-forme et de si on veut un code statique.

Comme tu peux l'imaginer, on est quand même forcé d'avoir Plugin = Implementation d'une classe abstraite (et rien d'autre). C'est deja pas mal.
J'ai aussi ajouté des paramètres que l'on peut passer au constructeur.

http://code.google.com/p/bugengine/s...stem/plugin.hh
http://code.google.com/p/bugengine/s...six/plugin.inl
http://code.google.com/p/bugengine/s...ole/plugin.inl

et comment on l'utilise?
Code:

1 2 3 4 Plugin<IRenderer> display("renderOpenGL", filesystem); ref<IRenderTarget> w = display->createRenderWindow(...); ref<IRenderTarget> w2 = display->createRenderWindow(...);