Discussion :

[Astraya]

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

[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

[Astraya]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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.

[Astraya]

Vous n'utilisez pas les conventions standards de VS.

Je ne les connais pas...

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 ).

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...?

[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 :/

[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 )

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.

[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

[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 :

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

[bacelar]

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.

[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

[Astraya]

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é?

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.

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

[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

[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?

[bacelar]

OUI.

[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

[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.

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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