Discussion :

[sfarc]

Bonjour,

J'utilise actuellement OpenCV pour du traitement d'images.
J'ai donc bien linké les .libs et ajouté le répertoire d'include dans mon projet.
Maintenant, pour que mon exécutable trouve les dll, je les colle directement dans les répertoires Debug et Release.

Or, je trouve ça un peu lourd comme manipulation, surtout si le projet est passé à quelqu'un et qu'il doit, au moment de la compilation, refaire la manipulation de son côté...
Y a-t-il un moyen de faire plus simple ?
Par exemple, laisser les dlls dans un répertoire ThirdParties et spécifier au moment de l’exécution ou les trouver ?

Quelle est la meilleure solution ?

Merci

[cob59]

Eventuellement, Opencv fournit des libs statiques qui permettent d'intégrer toutes les dépendances nécessaires à ton appli.

Si tu utilises CMake pour ton projet, il suffit de mettre OpenCV_STATIC à ON dans ton CMakeLists :

Code :

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

1
2
3
 
SET ( OpenCV_STATIC ON )
FIND_PACKAGE ( OpenCV COMPONENTS core highgui imgproc REQUIRED )

Sinon il suffit de préciser au linker d'utiliser le répertoire des libs statiques.
Exemple : C:\opencv\build\x86\vc10\staticlib

[koala01]

Salut,

Pour ne pas avoir à copier une dll dans le dossier de l'exécutable, tu peux éventuellement modifier la variable PATH de ton environnement en indiquant le dossier dans lequel la dll se trouve.

En lançant une "invite de commandes", tu peux par exemple introduire la commande

Code :

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

set PATH=%PATH%;c:\chemin\vers\dossier_de_la_dll

Tu peux aussi envisager de créer un fichier batch qui contienne quelque chose comme

Code :

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

1
2
3
4
 
@set PATH=%PATH%;c:\chemin\vers\dossier_de_la_dll
 
@call cmd

afin d'automatiser les choses.

Tu n'as alors "plus qu'à" lancer ton exécutable depuis la ligne de commandes

Ces deux solutions ont l'avantage:

• De ne pas nécessiter d'autorisation spéciale
• De ne modifier la variable PATH que temporairement

Enfin, si tu as les autorisations requises, tu peux envisager d'aller modifier la variable PATH de manière plus durable (en fait: de manière définitive) dans dans le panneau de configuration -> système et sécurité -> système ->modifier les paramètres -> onglet "paramètres système avancés" -> variables d'environnement (chemin donné sous windows 7, susceptible d'être légèrement différent ).

Cette dernière possibilité nécessite cependant les autorisations de niveau "administrateur" et *risque* de ne pas être possible sur des machines d'entreprises

[sfarc]

Merci à tous les deux pour votre aide .

Eventuellement, Opencv fournit des libs statiques qui permettent d'intégrer toutes les dépendances nécessaires à ton appli.

Effectivement cob59, c'est une possibilité ici mais à vrai dire, je n'aurais pas dû parler d'OpenCV , j'attendais une solution plus générale et donc indépendante des bibliothèques utilisées.

Pour ne pas avoir à copier une dll dans le dossier de l'exécutable, tu peux éventuellement modifier la variable PATH de ton environnement en indiquant le dossier dans lequel la dll se trouve.

Je viens d'essayer cette première méthode en allant moi-même ajouter une variable d'environnement au système et plus de problèmes de dlls .
Je garderai en tête la solution du bat qui a ses avantages!

Merci encore

[cob59]

Effectivement cob59, c'est une possibilité ici mais à vrai dire, je n'aurais pas dû parler d'OpenCV , j'attendais une solution plus générale et donc indépendante des bibliothèques utilisées.

Ca reste une solution générale, hein, pas du tout spécifique à OpenCV.
Beaucoup de bibliothèques fournissent des versions statiques de leurs libs.

[JolyLoic]

En lançant une "invite de commandes", tu peux par exemple introduire la commande

Code :

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

set PATH=%PATH%;c:\chemin\vers\dossier_de_la_dll

Tu peux aussi envisager de créer un fichier batch qui contienne quelque chose comme

Code :

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

1
2
3
4
 
@set PATH=%PATH%;c:\chemin\vers\dossier_de_la_dll
 
@call cmd

afin d'automatiser les choses.

Tu n'as alors "plus qu'à" lancer ton exécutable depuis la ligne de commandes

Tu n'es même pas obligé de faire ça dans un batch. Si ta DLL est chargée dynamiquement ou en delay-load, ça peut être ton exécutable qui positionne lui même cette variable avant chargement de la DLL.

[koala01]

Tu n'es même pas obligé de faire ça dans un batch. Si ta DLL est chargée dynamiquement ou en delay-load, ça peut être ton exécutable qui positionne lui même cette variable avant chargement de la DLL.

Aussi, mais alors, ca devient "système dépendant" dans le sens où l'exécutable ne connaitra qu'un certains nombre de dossiers dans lequel il est susceptible d'aller voir, non

[JolyLoic]

Ca dépend, l'exécutable a accès à plein d'informations (son propre chemin, auquel il peut ajouter des sous répertories, la registry windows, un fichier de configuration à parser...)

Un cas ou j'en ai eu besoin, c'était une DLL lancée par Excel, qui elle même avait besoin d'une DLL à nous. Le chemin de recherche par défaut était celui de l'exécutable d'excell, où on ne pouvait bien entendu pas mettre notre DLL. Le client lançait excel directement, pas par un batch, et on n'avait pas le droit de modifier le PATH global. Cette technique nous a bien rendu service (dans notre cas, notre première DLL lisait son propre répertoire, puis l'ajoutait au path).

[koala01]

Ca dépend, l'exécutable a accès à plein d'informations (son propre chemin, auquel il peut ajouter des sous répertories, la registry windows, un fichier de configuration à parser...)

Un cas ou j'en ai eu besoin, c'était une DLL lancée par Excel, qui elle même avait besoin d'une DLL à nous. Le chemin de recherche par défaut était celui de l'exécutable d'excell, où on ne pouvait bien entendu pas mettre notre DLL. Le client lançait excel directement, pas par un batch, et on n'avait pas le droit de modifier le PATH global. Cette technique nous a bien rendu service (dans notre cas, notre première DLL lisait son propre répertoire, puis l'ajoutait au path).

Ah, dans le cas où il faut rajouter un chemin connu de l'exécutable, cela peut en effet être une excellent solution, je ne dis pas le contraire.

Mais, dans le cas présent, il s'agit de trouver le "bon chemin d'acces" à une bibliothèque externe qui peut, classiquement, se trouver "virtuellement n'importe où".

A mon sens, ca rend les choses un peu plus compliquées