Discussion :

[divide]

Bonjour,

On m'a passé une librairie (projet visual studio) que je veux réutiliser dans mon projet Qt (compilé avec MingW/gcc).

Le problème c'est que le header principal du projet inclus plein de trucs spécifiques à visual studio, donc inutilisable tel quel dans mon projet Qt.

-Est-ce que je peux créer mon propre header "clean" pour mon projet Qt en déclarant uniquement les fonctions dont j'ai besoin dans le .lib, sans que ca pose de problème ?

-Est-ce que le fait que la librairie soit compilé sous visual studio va poser problème avec MingW (différentes conventions de nommage ?) Si oui, y a til moyen de contourner ce probleme ?

Merci !

header source:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <trucsinutiles>
#include <trucsspecifiquesVS>
 
A();
 
class B {
B();
B1();
B2();
}
 
class C {
C();
C1();
C2();
}
 
D();

header souhaité:

Code :

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

1
2
3
4
5
class B {
B();
B1();
B2();
}

[mala92]

Ah !!! Le mythe du "re-use" !!!!

Tu peux donner des exemples de nom de header ?

En général, ce n'est pas des header spécifique à Visual mais spécifique à Windows (et son SDK).

Tu vas sûrement devoir faire l'équivalent d'un programme multi plateformes. Ex :

Code :

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

1
2
3
4
5
6
7
8
9
#ifdef WIN32
#include <winsock.h>
#else
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
...
#endif

[divide]

Ce sont en effet des headers du Platform SDK Windows, qui n'existent pas dans le systeme Qt/MingW (je ne me rappelle pas précisement, il y en a une dizaine, mais "strsafe.h" pour n'en citer qu'un).

Le truc c'est que ces header windows ne sont pas utiles pour la déclaration de la classe "B" qui m'interesse. Du coup je me demande si dans Qt je peux juste créer un header vierge et recopier la déclaration de la classe B, en linkant dans les paramètres projet avec le .lib compilé par visual studio (meme si ce .lib inclus plus de trucs que juste la classe B).

[Ekleog]

Un .lib est inutilisable avec MinGW, si je me souviens bien.

[divide]

Pas vrai, j'utilise des .lib externe dans mon projet Qt/MinGW (OpenAL en l'occurence); dans le .pro tu rajoute LIBS += mylibrary.lib

Sinon quelqu'un a un avis sur la question ? Je pensais que c'était un problème basique...

[bretus]

Bonsoir,

Il faut bien noter qu'il y a deux types de .lib :
- Ceux qui permettent de se lier à une DLL (~code objet de la bibliothèque)
- Ceux qui correspondent à une bibliothèque statique (~point d'entrée de la DLL)

Si à la rigueur MinGW peut s'en sortir avec le premier type, ça me semble compromis pour le second (en particulier si c'est du C++ et pas du C).

Ensuite, ça n'est pas un problème basique, quand une bibliothèque dépend d'un compilateur par les bibliothèques qui l'accompagne, il peut être difficile de l'utiliser avec un autre compilateur.

Je te conseillerais la méthode mala92 (mais avec des #ifdef _MSC_VER car MinGW définit WIN32 de mémoire) ou la ré-écriture sur la base de fonctions standards ou bibliothèques multi-plateforme (Qt, boost par exemple).

Après, certaines bibliothèques sont tellement peu pensées en multi-plateforme qu'il vaut mieux les laisser profiter des avantages certains de strsafe.h et autres cadeaux empoisonnés dans leurs tombeaux...

Bye

[divide]

Mince, je pensais que c'était un problème beaucoup plus simple que ça
Merci pour la réponse en tout cas !
En tout cas impossible que je puisse me passer de cette librairie, va falloir que je trouve un workaround...

[JolyLoic]

Et si tu compilais ton code avec visual studio (la même version que celle qu'a utilisé la bibliothèque) ?

[divide]

Pas envisageable, c'est un projet Qt Creator multiplateforme (win/mac) de plusieurs dizaine de milliers de lignes...
Au pire je vais faire un .exe VS pour interfacer la librairie avec mon projet via des lignes de commande, si je trouve pas de vrai workaround :S

[JolyLoic]

La dernière fois que j'avais regardé, Qt compilait très bien avec visual studio. Il suffirait juste de modifier l'appel de qmake pour lui demander de générer des fichiers de compilation pour ce compilateur.

Je ne suggère pas de modifier le code, juste la manière de le compiler.

[bretus]

Pas envisageable, c'est un projet Qt Creator multiplateforme (win/mac) de plusieurs dizaine de milliers de lignes...
Au pire je vais faire un .exe VS pour interfacer la librairie avec mon projet via des lignes de commande, si je trouve pas de vrai workaround :S

Et ta fameuse bibliothèque non portable, tu en as besoin que sous windows?

[divide]

JolyLoic: je comprend que tu me propose cette solution, mais je ne peux vraiment pas me permetttre de changer tout le systeme de compilation maintenant, c'est vraiment un gros projet qui utilise des directives de compilation gcc, il a été validé par le QA et il est sur le point d'être release après 2 ans de développement.
Pour tout dire, la librairie que je dois intégrer est une librairie annexe de mon éditeur; ca ne fait donc pas partie du coeur de l'appli, je prefere donc trouver un workaround sur cette librairie plutot que sur mon projet.

bretus: cette librairie compile egalement sur mac avec xcode; mais la je ne me fais pas trop de soucis, il me semble que Qt Creator sur mac utilise aussi le compilateur de xcode.

En regardant plus attentivement le header principal de cette librairie, je vois que la classe qui m'interesse a été copié deux fois: une fois comme une classe C++, une autre fois comme une classe C (extern "C" { ... }).
Vous pensez que la classe C du .lib peut etre lu par MinGW ?

[JolyLoic]

C'est une lib statique ou dynamique ?

Si c'est une lib dynamique, l'interface C doit être portable. Si c'est une lib statique, tu peux la wrapper dans une lib dynamique (gérée avec visual C++) qui expose une interface en C. Vue la nature de la lib, cette interface devrait ne pas être trop grosse.

Par contre, ce n'est pas hyper sécurisé, tout le monde pouvant remplacer la DLL par une autre qui répond en permanence "ok, tout est bon". Ça ne demande plus aucun talent de désassemblage.