Quels outils pour un "makefile portable" ?

Version imprimable

11/02/2013, 07h19
Neckara

Quels outils pour un "makefile portable" ?

Bonjour,

Actuellement, je créé des petites bibliothèques avec QtCreator, il génère donc un .pro et un .pro.user.

Mais je souhaiterais que les personnes qui souhaiteraient compiler mes bibliothèques n'aient pas besoin de télécharger QtCreator et puissent, quelque soit leur OS et leur IDE, compiler et installer les bibliothèques ou importer le projet dans leur IDE pour pouvoir travailler dessus.

N.B. Il faudrait que la compilation et installation reste relativement simple pour être fait par des non-programmeurs.

J'ai tout de suite pensé à CMake, mais j'ai aussi entendu parler de SCons, automake et premake.

Quel(s) outil(s) me conseillez-vous? Pourquoi?
11/02/2013, 08h16
Ehonn

CMake est vraiment pratique et ne demande pas trop de ligne de code (contrairement au configure.ac que j'ai pu voir).
Pour l'utilisateur, c'est toujours la même procédure (cd build, cmake .., make, make install). De plus CMake permet de vérifier (facilement) si les dépendances sont déjà installées (find_package, find_library)
Avec Qt, il y a des commandes spécifiques (pour moc par exemple) (mais rien de bien méchant) :(

Les solutions de compilation ne sont pas exclusives :)
11/02/2013, 11h29
JolyLoic

Je plussoie largement l'utilisation de cmake. Le principal avantage que je lui voit est qu'il ne se contente pas de compiler du code, mais il génère des projets aux formats des IDE les plus courants, ce qui permet à ceux qui le souhaitent de travailler avec l'IDE de leur choix et de bénéficier des avantages procurés.

J'ai fait la transition sur une grosse base de vieux code de simples makefile vers cmake, et le fait de pouvoir sous windows utiliser visual studio, avec sa complétion, son intellisense et tout, était un grand avantage !
11/02/2013, 11h59
gbdivers

Citation:

N.B. Il faudrait que la compilation et installation reste relativement simple pour être fait par des non-programmeurs.

A mon sens, l'installation de Qt (1 seul fichier à installer en général sur windows et linux, sur mac il faut également XCode) est probablement le plus simple en général (ide, compilateur et libs installé)

La première question est est-ce que tu utilises Qt dans ton code ?

Si tu fais du C++ standard sans lib, il faudra quand même installer cmake et il faudra configurer l'ide si l'utilisateur ne l'a pas encore fait ou (pire) utiliser le mode console

Avec des libs (non Qt), on faudra installer séparément les libs, chacune ayant probablement leurs propres systèmes de compilation (j'aime beaucoup boost, mais il faut avouer que l'install sous windows est pénible...)
Déjà là, tu as perdu tous tes utilisateurs non dev :)

L'utilisation de Qt te permet d'avoir un seul code, une seule lib pour la majorité des fonctionnalités (ihm, réseau, fichier, etc),un seul ide, un seul système de compilation
Ca reste à mon sens le plus simple (pour débutant ou non)
(et le moc, osef, perso, j'ai jamais eu à l'appeler manuellement en utilisant qt Creator)

Sinon, le plus simple reste quand même de fournir tes libs déjà compilé :)
11/02/2013, 12h18
Neckara

Citation:

Envoyé par gbdivers

La première question est est-ce que tu utilises Qt dans ton code ?

Non, je n'utilise pas Qt pour des raisons de licences.

Citation:

Envoyé par gbdivers

Avec des libs (non Qt), on faudra installer séparément les libs, chacune ayant probablement leurs propres systèmes de compilation (j'aime beaucoup boost, mais il faut avouer que l'install sous windows est pénible...)
Déjà là, tu as perdu tous tes utilisateurs non dev :)

Je suis un peu obligé d'utiliser boost :aie:

Citation:

Envoyé par gbdivers

L'utilisation de Qt te permet d'avoir un seul code, une seule lib pour la majorité des fonctionnalités (ihm, réseau, fichier, etc),un seul ide, un seul système de compilation
Ca reste à mon sens le plus simple (pour débutant ou non)
(et le moc, osef, perso, j'ai jamais eu à l'appeler manuellement en utilisant qt Creator)

Certains programmeurs/utilisateurs n'ont peut être pas envie de télécharger QtCreator juste pour ça (et certains n'aiment peut être pas QtCreator ou préfèrent un autre IDE).
De plus, dès qu'on change de poste, il faut éditer quelques paramètres dans le .pro

Citation:

Sinon, le plus simple reste quand même de fournir tes libs déjà compilé :)

Je ne peux pas les compiler moi-même pour toutes les plate-formes, je préfère donc les compiler pour les plate-formes que je possèdes et fournir un moyen de les compiler soit-même (et de me les soumettre pour rajouter le nombre de versions disponibles).
De plus, je ne vais pas tout recompiller à chaque commit mais plutôt à chaque sortie de release.

Sinon j'ai commencé à lire un tutoriel sur CMake, j'ai vu qu'il est possible de générer des fichiers de projet à partir de fichiers CMake, mais est-il possible (et recommandable) de faire l'inverse?
11/02/2013, 18h05
Neckara

J'ai fini le tutoriel sur CMake et je suis un peu perplexe.

Apparemment, il faut renseigner dans le CMakecache les dossiers où trouver les bibliothèques ainsi que les dossiers où stocker le résultat de la compilation même si on compile une bibliothèque. Et ce pour chaque architecture/distribution. :aie:
Cela me parait vraiment très étrange...

Pour les bibliothèques requises, on peut utiliser le module Find, qui permettrait de trouver les bibliothèques plus facilement mais j'ai du mal à comprendre son fonctionnement et son utilité.
Sinon, si une dépendance (source/bibliothèque) est manquante, est-il possible d'indiquer une URL où la télécharger et de la compiler automatiquement dans le cas d'une bibliothèque ?
11/02/2013, 22h06
JolyLoic

Pour les bibliothèques, il y a deux philosophies :

1 - Soit on considère que toutes les machines devant compiler le code seront assez semblables, avec les diverses bibliothèques installées au même endroit (par exemple, parce qu'elles sont stockées dans le système de gestion de code, parce qu'il y a une ghost qui sert de point de départ de toute machine de développement...). C'est assez souvent le cas chez un éditeur logiciel assez centralisé.

Dans ce cas, des fonctionnalités comme find ne servent à rien d'autre qu'à fragiliser le système. Pour utiliser ces bibliothèques, il suffit d'utiliser les chemins relatifs/variables d'environnement... qui vont bien.

2 - Soit on considère que les machines où le code va être compilées sont sans aucun contrôle, que chacun va utiliser une version différente de la bibliothèque installée où il l'a voulue. C'est probablement un modèle plus répandu pour le développement de code libre.

Là, un système comme find va regarder aux endroits classiques d'installation et s'adapter automatiquement (dans la mesure du possible) à l'environnement de compilation sur lequel il se trouve.
11/02/2013, 22h15
Neckara

Mais les "endroits" classiques d'installations peuvent changer selon la distribution Linux et sous Windows c'est un peu l'anarchie il me semble.

Donc on essaye de mettre les dossiers les plus "répandus" et si l'utilisateur n'a pas une configuration habituelle, il doit modifier le cmakecache à la main ?

Pour installer des bibliothèques ou en rechercher, est-ce que CMake génère automatiquement dans le cmake cache une variable contenant le chemin "usuel"/"officiel"/"par défaut" vers les bibliothèques sur l'environnement où on se trouve ?
11/02/2013, 22h37
bretus

Bonjour,

Citation:

Envoyé par Neckara

Donc on essaye de mettre les dossiers les plus "répandus" et si l'utilisateur n'a pas une configuration habituelle, il doit modifier le cmakecache à la main ?

Heu, avec cmake-gui plutôt non?

[EDIT]Sinon, il y a les cmake -DLALIB_DIR="chemin/vers/lalib"
12/02/2013, 03h54
Joker-eph

Citation:

Envoyé par Neckara

J'ai fini le tutoriel sur CMake et je suis un peu perplexe.

Apparemment, il faut renseigner dans le CMakecache les dossiers où trouver les bibliothèques ainsi que les dossiers où stocker le résultat de la compilation même si on compile une bibliothèque. Et ce pour chaque architecture/distribution. :aie:
Cela me parait vraiment très étrange...

Hum, es-tu sûr ? Normalement tu ne fais RIEN dans le CMakeCache, c'est automatiquement généré par CMake justement, à partir de la description de tes dépendances. Par exemple tu déclares avoir besoin de boost et automatiquement CMake ajoute dans le CMakeCache les chemins et paramètres qui vont bien pour le compilateur.
12/02/2013, 06h18
Neckara

Citation:

Envoyé par Joker-eph

Hum, es-tu sûr ? Normalement tu ne fais RIEN dans le CMakeCache, c'est automatiquement généré par CMake justement, à partir de la description de tes dépendances. Par exemple tu déclares avoir besoin de boost et automatiquement CMake ajoute dans le CMakeCache les chemins et paramètres qui vont bien pour le compilateur.

C'est ce qui est dit ici : http://florian-goujeon.developpez.co...nitiation/#LIV

Et pour le Find c'est identique vu qu'on ne spécifie pas un chemin mais plusieurs.
12/02/2013, 09h04
bretus

Citation:

Envoyé par Neckara

C'est ce qui est dit ici : http://florian-goujeon.developpez.co...nitiation/#LIV

Et pour le Find c'est identique vu qu'on ne spécifie pas un chemin mais plusieurs.

Je comprend mal ta remarque. Les lignes du cache du type : "BOOST_INCLUDEDIR:FILEPATH=/chemin/vers/boost_x_xx_x" sont définies automatiquement par des commandes du style "find_path" ou "find_library" dans FindBoost.cmake.

Je te conseillerais facilement d'essayer de faire un finder pour une de tes dépendances en t'inspirant de celui ci : Modules/FindCURL.cmake. Tu trouveras plus de détail ici.
12/02/2013, 10h58
Neckara

Citation:

Envoyé par bretus

Je comprend mal ta remarque. Les lignes du cache du type : "BOOST_INCLUDEDIR:FILEPATH=/chemin/vers/boost_x_xx_x" sont définies automatiquement par des commandes du style "find_path" ou "find_library" dans FindBoost.cmake.

"find_path" ou "find_library" ne sont pas magiques et se basent sur des chemins spécifiés dans les arguments.

Mais apparemment, il y a une option qui permet d'utiliser le path ( ENV PATH) du système utilisé (mais est-ce qu'on peut obtenir le path de toutes les plateformes/distributions ?).

Ceci résout donc le problème de recherche des dépendances.
Pour le téléchargement et l'installation des dépendances manquantes, apparemment il serait possible de le faire avec CPack.

Par contre comment savoir quel est le dossier à utiliser pour stocker les bibliothèques à compiler ? On le laisse au choix de l'utilisateur ?
N'y a-t-il pas comme avec "ENV PATH", un moyen de récupérer le chemin "préféré" pour stocker les bibliothèques ?

Donc si je résume :

- Recherche des dépendances avec Find (+ ENV PATH) ;
- Si pas trouvé, utilisation d'un CPack dédié (?) pour installer la dépendance manquante (mais il faut savoir où enregistrer les données) ;
- Une fois toutes les dépendances trouvées, on peut enfin générer le makefile/fichier de projet etc...

Il faut savoir que pour les libs les plus répandues (boost, freetype, curl, Qt, ...), CMake possède déjà les fichiers find qui vont bien et il est alors possible de faire ce genre de choses :
Code:

1 2 3 4 5 6 7 8 9 10 find_package( Boost ) # Va rechercher boost et mettre les entrées qui vont bien dans le cache # S'il ne le trouve pas, l'entrée BOOST_FOUND sera à FALSE et donc : if(BOOST_FOUND) MESSAGE( STATUS "Found Boost" ) #On peut continuer else() #On ne continue pas MESSAGE( ERROR "Boost not found" ) endif()
Si la lib n'est pas trouvée (Boost pour continuer mon exemple) tu auras une entrée de type <Lib>_ROOT_DIR (Boost_INCLUDE_DIR pour Boost) à renseigner dans le cache.

Une fois cette entrée renseignée avec le bon chemin, il suffit de relancer CMake.

Pour les libs moins connues, comme des libs personnelles, tu peux créer toi-même un fichier Find<MaLib>.cmake (par exemple : FindFreeImage.cmake).

Dans ton CMakeLists.txt tu pourras alors faire : find_package( <MaLib> )#Respecter la casse.

Si ton fichier FindXXX est bien fait tu auras toi-même prévu l'entrée <MaLib>_ROOT_DIR qui permettra de déduire le dossier d'include, de libs, bin...

Au final tu te tapes la majeure partie du boulot pour qu'au final l'utilisateur n'ait au pire que quelques chemins à renseigner.

EDIT :
Pour l'édition du cache, je recommande évidemment cmake-gui (et même cmake-qtgui si disponible) qui simplifie bien la tâche de l'utilisateur final et même le tien pendant le réglage de ton CMakeLists.txt

12/02/2013, 13h26
Neckara

Citation:

Envoyé par dragonjoker59

Au final tu te tapes la majeure partie du boulot pour qu'au final l'utilisateur n'ait au pire que quelques chemins à renseigner.

Dans le cas où la bibliothèque n'est pas trouvée, je peux lui proposer de l'installer directement ?
Est-ce possible de le faire de même avec le compilateur (s'il n'y a pas de compilateur installé de proposer une installation) ?

Sinon avec CPack, je générer à partir du CMakeList.txt des installateurs/paquets pour que n'importe qui (même un non-informaticien) puisse installer le programmes + bibliothèques recquises ?
Mais est-il possible de générer tout les installateur/paquets possible à partir de CPack ?
12/02/2013, 14h03
dragonjoker59

Non, pour les libs manquantes l'utilisateur devra les télécharger lui-même et si besoin est les compiler par la même occasion.

Pour CPack je ne peux pas te renseigner, je ne l'utilise pas.
12/02/2013, 15h47
Neckara

Citation:

Envoyé par dragonjoker59

Non, pour les libs manquantes l'utilisateur devra les télécharger lui-même et si besoin est les compiler par la même occasion.

Donc si j'ai 50 dépendances, il faut que l'utilisateur se fasse 50 compilations et installations de bibliothèques à la suite en allant rechercher à chaque fois où trouver la lib ?

Je me suis déjà retrouvé à devoir compiler je-ne-sais-combien de dépendances pour un logiciel de traitement de son, c'est vraiment pas pratique :aie:
12/02/2013, 15h52
dragonjoker59

La solution serait donc de livrer les dépendances en même temps que les sources de ton projet, ainsi tu résous toi même tous les problèmes, mais c'est toi qui devras tout configurer afin de compiler toutes les dépendances, toussa...
12/02/2013, 19h53
Neckara

Je trouve que c'est un peu casse-tête...

Je ne comprend pas qu'il n'existe pas de protocole répandu qui permettrait la compilation de tout et n'importe quoi juste en connaissant le compilateur a utiliser, les dépendances ainsi que des URLs où trouver les dépendances manquantes et/ou télécharger de quoi générer les dépendances manquantes.

Ce ne serait pas super compliqué à implémenter, il suffirait juste qu'une grande majorité l'utilise et on aurait même plus à se prendre la tête :cry:

Je pense que le plus simple va être de :
- créer un petit wiki où on pourra ajouter le résultat de sa compilation ;
- fournir un CMakeList.txt pour chaque "projet" simple qui lorsqu'il ne trouve pas une de mes bibliothèque donnera l'URL où trouver la dépendance manquante (ça doit être possible d'afficher un message personnalisé je pense (?) );
- fournir un gros CMakeList.txt avec un zip de toute mes bibliothèques pour qu'il compile le tout ;
- indiquer dans le CMakeList les dépendances qui ne sont pas des bibliothèques (ex : images, sons).

Je m'assure juste que ça marche pour ma distribution, si ça ne marche pas chez quelqu'un, il modifie et fera part de ses modifications.
Et si une dépendance qui ne fait pas partie de mes bibliothèques n'est pas trouvée, à l'utilisateur de se débrouiller lui-même.

Est-ce une bonne stratégie ? J'ai un peu l'impression de dire à l'utilisateur "démerdes-toi", mais d'un autre côté je n'ai pas envie de passer 10 ans dessus.
Cela me dérange vraiment de ne pas pouvoir fournir des fichiers de configurations qui permettraient de tout compiler "en un clic".
12/02/2013, 20h28
bretus

Citation:

Envoyé par Neckara

Je ne comprend pas qu'il n'existe pas de protocole répandu qui permettrait la compilation de tout et n'importe quoi juste en connaissant le compilateur a utiliser, les dépendances ainsi que des URLs où trouver les dépendances manquantes et/ou télécharger de quoi générer les dépendances manquantes.

Idem, mais ça, il faut s'en prendre aux gens qui se battent pour une liberté futile dans l'organisation des sources...

Si on regarde la réaction des langages comme PHP quand c'est devenu le merdier, des conventions ont été posée dans le standard et hop : Composer.

Mais en C++, tant que la template va, tout va. Qu'il soit impossible de gérer de manière standard des dépendances et des compilations : Tout le monde s'en cogne. Qu'il faille passer des moc et autres cochonneries pour enrichir le runtime : C'est la même.

Espérons que les travaux sur les modules permettent d'y mettre un peu d'ordre, en attendant, cmake & co sera un moindre mal.

Note : Ce que cmake gère mal, ce sont les dépendances des dépendances en compilation statique (l'utilisateur doit savoir que boost::thread va se mettre à dépendre de boost::chrono)
12/02/2013, 20h39
Joker-eph

Citation:

Envoyé par Neckara

C'est ce qui est dit ici : http://florian-goujeon.developpez.co...nitiation/#LIV

Et pour le Find c'est identique vu qu'on ne spécifie pas un chemin mais plusieurs.

Ce n'est pas ce qui est écrit. Il est bien dit que le CMakeLists.txt est indépendant et que c'est ce fichier que tu distribues. Le CMakeCache est automatiquement généré et SI tu as une installation exotique tu peux avoir à y préciser les chemins. Mais vu que c'est lié à l'environnement, ce n'est pas prévisible et il n'y a rien à faire côté packaging.

Côté dépendances, c'est lié à l'OS aussi. Un paquet debian/ubuntu/fedora/... peut très bien lister ce que tu veux comme dépendances. Le problème reste le boulot que tu auras à valider ça à chaque nouvelle version de distribution.

Après tu dis faire des "petites bibliothèques", avec 50 dépendances je réfléchirai bien avant d'avoir à l'inclure dans un projet.
12/02/2013, 20h45
Joker-eph

Citation:

Envoyé par Neckara

Donc si j'ai 50 dépendances, il faut que l'utilisateur se fasse 50 compilations et installations de bibliothèques à la suite en allant rechercher à chaque fois où trouver la lib ?

En général on package pour une distribution et le gestionnaire de paquet gère tout seul. On peut aussi simplement lister les dépendances et l'utilisateur fait appel à son gestionnaire de paquet pour installer tout ça.

Exemple : http://ceph.com/docs/master/install/...prerequisites/

L'utilisateur au moment où il lance CMake (ou autre build-system) aura un joli message indiquant les dépendances manquantes le cas échéant.
12/02/2013, 22h33
Neckara

Citation:

Envoyé par Joker-eph

En général on package pour une distribution et le gestionnaire de paquet gère tout seul. On peut aussi simplement lister les dépendances et l'utilisateur fait appel à son gestionnaire de paquet pour installer tout ça.

Exemple : http://ceph.com/docs/master/install/...prerequisites/

L'utilisateur au moment où il lance CMake (ou autre build-system) aura un joli message indiquant les dépendances manquantes le cas échéant.

Tous les programmeurs ne sont pas sous Linux :aie:
Et il va bien falloir compiler pour Windows vu que généralement, la majorité du public cible s'y trouve...
13/02/2013, 00h39
LittleWhite

Citation:

Envoyé par Neckara

Tous les programmeurs ne sont pas sous Linux :aie:
Et il va bien falloir compiler pour Windows vu que généralement, la majorité du public cible s'y trouve...

Sauf que sous Windows, tu fait juste une version 32 bits, avec tes libs, tu distribue cela en tout fermé et hop, t'a fini (Oui, pas de portage 64 bits, notamment car en ayant la mentalité le code fermé, y aura personne pour compiler en natif (vivement Windows RT tient) et que en plus, le peu qui s'y intéresse, trouveront trop pénible à faire une app pour les deux).
Ce que je veux dire, c'est au nombre de jeu ou autre trucs qui restent en 32bits, les dépendances sont vites gérés : Tu files les DLL en 32 bits, dans la versions que tu veux de l'exécutable et hop fini

Après, le système qui sera mieux, ce sera de faire des builds automatisé ou tout le environnement de travail pourra être récupérer par un script et mis à jour automatiquement. Il y a des solutions qui existent, sinon, il y a faire à la main.

Mais bon, en dernier conseil, si tu as commencé un projet et que tu bosse sur un truc "instable", c'est d'avoir une copie locale de la version utilisée de la bibliothèque. Car si le truc instable change trop, le code de ton projet sera tout cassé tous les deux changements.

EDIT :
Pour le cas projet Windows et Linux, ce sont les dosiers lib qui contiennent les bons fichiers. Je veux dire par là, à coté des .so tu as les .lib. Tout simplement. CMake comprendra (en ajoutant le répertoire dans la configuration bien entendu) et le projet est compilable sur les deux OS. Je le faisais avec OpenAWars, mais plus récemment tu as ceci : http://jeux.developpez.com/telecharg...Exemple-de-FBO . Un projet CMake avec les dépendances de définie. Le gars sous Linux, il fait un aptitude/yum/emerge/pacman ou je sais pas quoi qui veut pour installer les bibliothèques en développement voulues. Le gars sous Windows, tout est livré, juste à installer CMake. Dans les deux cas, le projet compile. Windows avec les .DLL/.lib que je livre, Linux avec les .so dans le système.
13/02/2013, 02h03
Joker-eph

Citation:

Envoyé par Neckara

Tous les programmeurs ne sont pas sous Linux :aie:
Et il va bien falloir compiler pour Windows vu que généralement, la majorité du public cible s'y trouve...

"La majorité du public cible s'y trouve", hum... selon le domaine d'application...

Bref de toute façon je n'ai mentionné que Linux parce que sous Windows ça me semblait plus simple, comme LittleWhite l'a expliqué.
13/02/2013, 08h20
Neckara

@LittleWhite : merci pour ta réponse.
Il va donc falloir que je me paye la compilation + installation des bibliothèques sous windows moi-même :aie:

Sauf que c'est loin d'être aussi simple que tu le dis car il faut sous Windows fournir les bibliothèques compilée... pour chaque compilateur (et même version de compilateur !)

En effet, j'ai déjà eu un tel problème en utilisant une version de bibliothèque compilée pour VS alors que j'utilisais mingw32.
J'ai aussi un ami qui n'arrivais pas à utiliser openCV avec mingw32 parce qu'il avait une version de mingw32 différente...

Pour les bibliothèques, j'utilise pour le moment :
- boost
- Irrlicht 3D
- openSSL

Il faut donc que je copie les sources dans un endroit au cas où puis que je créé un petit dossier /usr/include/monProjet où je mette tous mes header et dans /usr/lib/monProjet tous mes .a ?
C'est à dire utiliser dès maintenant une version "figée" des bibliothèques ?
Est-ce vraiment recommandable ?
Faut-il faire de même pour le compilateur ?

@Joker-eph : au contraire, sous Linux, on a juste un aptitude install à faire, c'est de loin le plus simple.
Sous Windows, il faut déjà arriver à compiler certaines bibliothèques pour pouvoir les distribuer par le suite :aie:
13/02/2013, 08h32
LittleWhite

Citation:

Envoyé par Neckara

Il va donc falloir que je me paye la compilation + installation des bibliothèques sous windows moi-même :aie:

Ouep, enfin, toutes bibliothèques n'obligent pas la recompilation. Exemple, la SDL a les binaires tout comme il faut.

Citation:

Sauf que c'est loin d'être aussi simple que tu le dis car il faut sous Windows fournir les bibliothèques compilée... pour chaque compilateur (et même version de compilateur !)

Pour chaque compilateur, oui cela peut être vrai (remarquez que la SDL propose une version MinGW et une version VS).
Après, comme je l'ai dit, avec un système automatisé, ça peut être facile. Après, on peut toujours faire des contraintes de projet, si nous n'avons pas de supporteurs (dire que le projet est uniquement compatible avec tel compilateur). Sachant que MSVC ne supporte pas complètement le C++11 (pas aussi bien que MinGW, le choix est vite fait :aie:). Et puis, il est moins pénible d'installer un MinGW gratuit qu'un MSVC qui vient uniquement avec un éditeur.

Citation:

J'ai aussi un ami qui n'arrivais pas à utiliser openCV avec mingw32 parce qu'il avait une version de mingw32 différente...

Légèrement étonnant, les incompatibilité des fichiers me semblait surtout exister entre MinGW et MSVC (.a et .lib). Après, cela peut dépendre de commencer est compilé OpenCV aussi.

Citation:

Il faut donc que je copie les sources dans un endroit au cas où puis que je créé un petit dossier /usr/include/monProjet où je mette tous mes header et dans /usr/lib/monProjet tous mes .a ?

En théorie, cela devait déjà être le cas à la création du projet (sauf pour Linux et encore, que si les bibliothèque sont dans les paquets)

Citation:

C'est à dire utiliser dès maintenant une version "figée" des bibliothèques ?

Moi, c'est ce que je conseille, surtout pour des bibliothèques en cours de développement.

Citation:

Est-ce vraiment recommandable ?

Je donne juste des conseils sur des expériences que j'ai eu. Mon cas était un peu étrange, car c'était en D. La bibliothèque OpenGL est porté par des contributeurs et entre deux versions de leurs SVN, ils ont changé la gestion des extensions. Le jour où je suis passé de Linux à Windows, que j'ai récupérer la nouvelle version de la bibliothèque, j'ai eu mal. Pour cela que je conseille de garder une version fixe de la bibliothèque, surtout si celle-ci est en développement (ou beta).

Citation:

Faut-il faire de même pour le compilateur ?

Je doute que vous ne changiez de compilateur en cours de projet et cela même, je n'en vois pas la raison. Et puis, un code bien écrit est sensé compiler avec tous les compilateurs conformes à la norme, non ?

Une autre possibilité, si vraiment vous êtes parano, c'est de garder les installateurs des compilateurs/bibliothèques dans la version du projet. Je veux dire par là, un dossier bin, qui contient l'installateur de MinGW, les installateurs des bibliothèques, les redistribuables (si besoin) et tout ça. Quelqu'un qui débarque sur le projet, prend le SVN, lance les installateurs et hop, c'est tout ok.
13/02/2013, 08h51
Neckara

Merci pour tes réponses.

Par contre pour Boost et OpenSLL, c'est une horreur pour le compiler sous Windows...
ça va représenter pas mal de travail ça :aie:

Bonjour,

J'ai tenté de faire quelques CMakeLists.txt et je reconnais que c'est plutôt simple.
Par contre pour l'écriture de FindXXX.cmake, je reste encore un peu perdu.
J'ai regardé le FindSDL.cmake pour m'en inspirer un peu mais il ne semble pas avoir de "sous-modules" comme boost avec system, thread, ...
De plus, je n'arrive pas à afficher un message si la bibliothèque est trouvée ou non....

J'ai aussi regardé le FindBoost.cmake .... :aie:

Ci-dessous les deux fichiers que j'ai créé, qu'en pensez-vous ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 cmake_minimum_required(VERSION 2.6) project(LDDataBase) find_package ( LD 1 REQUIRED error ) if( ${LD_FOUND} ) MESSAGE( STATUS " Found LD" ) #On peut continuer else() #On ne continue pas MESSAGE( FATAL_ERROR " LD not Found" ) endif() find_package( Boost 1.46.1 REQUIRED system ) set(LIBRARY_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE}) file ( GLOB_RECURSE source_files ../src/* ) add_library( LDdatabase SHARED ${source_files} ) set(CMAKE_CXX_FLAGS "-std=c++11") ##We use C++11 include_directories(../include ${LD_LIBRARY_DIRS} ${Boost_LIBRARY_DIRS} ) link_directories( ${LD_INCLUDE_DIRS} ${Boost_INCLUDE_DIRS}) target_link_libraries( LDdatabase ${LD_LIBRARIES} ${Boost_LIBRARIES})
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 # All rights reserved # Official Website : http://jsz.kegtux.org/ find_path( LD_INCLUDE_DIR NAMES exception.h Error_global.h HINTS C:/includes/ HINTS /user/include/ PATH_SUFFIXES LastDungeon ) find_library( LD_LIBRARY_DIRS NAMES LDerror HINTS C:/bin/ HINTS /user/include/ PATH_SUFFIXES lib LastDungeon ) set( LD_LIBRARIES "LDerror") set(LD_PROCESS_INCLUDES ${LD_INCLUDE_DIRS} ) set(LD_PROCESS_LIBS ${LD_LIBRARIES} ) #libfind_process(LD)
EDIT : en fait si je n'obtenais rien, c'est que je copiais le mauvais fichier .cmake dans le dossier de Cmake :aie:

Pour le moment ça marche quand il ne trouve pas, je vais tester quand il doit trouver ;)

Mais je ne vois toujours pas comment ne rechercher que des modules de ma bibliothèque.

Bonjour,

Citation:

Envoyé par Neckara

Mais je ne vois toujours pas comment ne rechercher que des modules de ma bibliothèque.

Quand tu fais

Code:

find_package( MaLib COMPONENTS gui core REQUIRED )

cmake définit la variable MaLib_FIND_COMPONENTS pour ton finder.

Du coup, pour peu que tu ais pris une convention sur le nom de tes bibliothèques (style MaLib_<composant>), tu t'en sors dans FindMaLib.cmake avec une chose du style :
Code:

1 2 3 4 5 6 7 8 9 foreach( MaLib_FIND_COMPONENT ${MaLib_FIND_COMPONENTS} ) FIND_LIBRARY(MaLib_${MaLib_FIND_COMPONENT}_LIBRARY NAMES MaLib_${MaLib_FIND_COMPONENT} HINTS ${BASE_HINTS} PATH_SUFFIXES lib64 lib PATHS ${BASE_PATHS} ) endforeach()

Merci pour ta réponse.

J'ai essayé de m'en inspirer mais j'ai maintenant 3 pages de warnings :aie:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 # All rights reserved # Official Website : http://jsz.kegtux.org/ foreach( LD_FIND_COMPONENT ${LD_FIND_COMPONENTS} ) FIND_LIBRARY( LD${LD_FIND_COMPONENT}_LIBRARY NAMES LD${LD_FIND_COMPONENT} HINTS ${BASE_HINTS} PATH_SUFFIXES LastDungeon lib lib64 . PATHS ${BASE_PATHS} C:/bin/ /usr/lib/ ) endforeach() foreach( LD_FIND_COMPONENT ${ LD_FIND_COMPONENTS} ) FIND_LIBRARY( LD${LD_FIND_COMPONENT}_INCLUDE_DIRS NAMES ${LD_FIND_COMPONENT}.h HINTS ${BASE_HINTS} PATH_SUFFIXES LastDungeon include . PATHS ${BASE_PATHS} C:/includes/ /usr/include/ ) endforeach() foreach( LD_FIND_COMPONENT ${ LD_FIND_COMPONENTS} ) set( LD${LD_FIND_COMPONENT}_LIBRARIES LD${LD_FIND_COMPONENT} ) endforeach() # set(LD_PROCESS_INCLUDES ${LD_INCLUDE_DIRS} ) # set(LD_PROCESS_LIBS ${LD_LIBRARIES} ) set( LD_FOUND true) foreach( LD_FIND_COMPONENT ${ LD_FIND_COMPONENTS} ) if( NOT ${LD${LD_FIND_COMPONENTS}_INCLUDE_DIRS} OR NOT ${LD${LD_FIND_COMPONENTS}_LIBRARIES } ) set( LD_FOUND false ) set( LD${LD_FIND_COMPONENTS}_FOUND false ) else () set( LD${LD_FIND_COMPONENTS}_FOUND true ) endif() endforeach() #libfind_process("LD")
Citation:

CMake Warning (dev) at /usr/share/cmake-2.8/Modules/FindLD.cmake:4 (foreach):
Syntax error in cmake code at

/usr/share/cmake-2.8/Modules/FindLD.cmake:4

when parsing string

${

syntax error, unexpected $end, expecting } (2)

Policy CMP0010 is not set: Bad variable reference syntax is an error. Run
"cmake --help-policy CMP0010" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
Call Stack (most recent call first):
CMakeLists.txt:5 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) at /usr/share/cmake-2.8/Modules/FindLD.cmake:15 (foreach):
Syntax error in cmake code at

/usr/share/cmake-2.8/Modules/FindLD.cmake:15

when parsing string

${

syntax error, unexpected $end, expecting } (2)

Policy CMP0010 is not set: Bad variable reference syntax is an error. Run
"cmake --help-policy CMP0010" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
Call Stack (most recent call first):
CMakeLists.txt:5 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
[...]

EDIT :
J'ai trouvé l'erreur, il fallait utiliser ${LD_FIND_REQUIRED} et non ${LD_FIND_COMPOMENT}

Je pense avoir presque fini :

Citation:

# All rights reserved
# Official Website : http://jsz.kegtux.org/

foreach( LD_FIND_COMPONENT ${LD_FIND_REQUIRED} )
FIND_LIBRARY(
LD${LD_FIND_COMPONENT}_LIBRARY
NAMES LD${LD_FIND_COMPONENT}
HINTS ${BASE_HINTS}
PATH_SUFFIXES LastDungeon lib lib64 .
PATHS ${BASE_PATHS} C:/bin/ /usr/lib/
)
if( NOT ${LD_LIBRARY} )
set( LD_LIBRARY LD${LD_FIND_COMPONENT}_LIBRARY)
else ()
set( LD_LIBRARY "$LD_LIBRARY LD${LD_FIND_COMPONENT}_LIBRARY")
endif()
endforeach()

foreach( LD_FIND_COMPONENT ${LD_FIND_REQUIRED} )
FIND_LIBRARY(
LD${LD_FIND_COMPONENT}_INCLUDE_DIRS
NAMES ${LD_FIND_COMPONENT}.h
HINTS ${BASE_HINTS}
PATH_SUFFIXES LastDungeon include .
PATHS ${BASE_PATHS} C:/includes/ /usr/include/
)
if( NOT ${LD_INCLUDE_DIRS} )
set( LD_LIBRARY LD${LD_FIND_COMPONENT}_INCLUDE_DIRS)
else ()
set( LD_LIBRARY "$LD_INCLUDE_DIRS LD${LD_FIND_COMPONENT}_INCLUDE_DIRS")
endif()

endforeach()

foreach( LD_FIND_COMPONENT ${LD_FIND_REQUIRED} )
set(
LD${LD_FIND_COMPONENT}_LIBRARIES
LD${LD_FIND_COMPONENT}
)
if( NOT ${LD_INCLUDE_DIRS} )
set( LD_LIBRARY LD${LD_FIND_COMPONENT}_LIBRARIES)
else ()
set( LD_LIBRARY "$LD_LIBRARIES LD${LD_FIND_COMPONENT}_LIBRARIES")
endif()
endforeach()

# set(LD_PROCESS_INCLUDES ${LD_INCLUDE_DIRS} )
# set(LD_PROCESS_LIBS ${LD_LIBRARIES} )

set(LD_FOUND 1)

14/02/2013, 16h46
bretus

${ LD_FIND_COMPONENTS} <= un vilain espace là dedans

Edit : j'ai lu que le début xD

Merci pour ta réponse.

J'ai presque fini, juste un petit problème dans les boucles de recherches, dès qu'un élément est trouvé, il ne va plus modifier la variable pour mettre <var>-NOTFOUND dedans.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# All rights reserved
# Official Website : <a href="http://jsz.kegtux.org/" target="_blank">http://jsz.kegtux.org/</a>
 
set(LD_FOUND 1)
 
message("Search ${LD_FIND_COMPONENTS} 's LastDungeon" )
 
set( LD_LIBRARY_DIRS "")
 
foreach( LD_FIND_COMPONENT ${LD_FIND_COMPONENTS} )
	FIND_LIBRARY(
		LD_TEMP_LIBRARY
		NAMES LD${LD_FIND_COMPONENT}
		HINTS ${BASE_HINTS}
		PATH_SUFFIXES LastDungeon lib lib64 .
		PATHS ${BASE_PATHS} C:/bin/ /usr/lib/
	)
	set(LD${LD_FIND_COMPONENT}_LIBRARY ${LD_TEMP_LIBRARY} )
 
	STRING(COMPARE EQUAL ${LD_TEMP_LIBRARY} "LD_TEMP_LIBRARY-NOTFOUND" RESULT)
 
	if( ${RESULT} )
		message(ERROR " : Library LD${LD_FIND_COMPONENT} not found : ${LD_TEMP_LIBRARY}")
		set(LD_FOUND 0)
	else ()
		message("Library LD${LD_FIND_COMPONENT} found : ${LD_TEMP_LIBRARY}")
	endif()
 
	set( LD_LIBRARY_DIRS "${LD_LIBRARY_DIRS} ${LD_TEMP_LIBRARY}" )
endforeach()
 
set( LD_INCLUDE_DIRS "")
 
foreach( LD_FIND_COMPONENT ${LD_FIND_COMPONENTS} )
	FIND_LIBRARY(
		LD_TEMP_INCLUDE_DIRS
		NAMES ${LD_FIND_COMPONENT}.h
		HINTS ${BASE_HINTS}
		PATH_SUFFIXES LastDungeon include .
		PATHS ${BASE_PATHS} C:/includes/ /usr/include/
	)
	set(LD${LD_FIND_COMPONENT}_INCLUDE_DIRS ${LD_TEMP_INCLUDE_DIRS} )
 
 
	STRING(COMPARE EQUAL ${LD_TEMP_INCLUDE_DIRS} "LD_TEMP_INCLUDE_DIRS-NOTFOUND" RESULT)
 
	if( ${RESULT} )
		set(LD_FOUND 0)
		message(ERROR " : Header ${LD_FIND_COMPONENT}.h not found : ${LD_TEMP_INCLUDE_DIRS}")
	else ()
		message("Header ${LD_FIND_COMPONENT}.h found : ${LD_TEMP_INCLUDE_DIRS}")
	endif()
 
	set( LD_INCLUDE_DIRS "${LD_INCLUDE_DIRS} ${LD_TEMP_INCLUDE_DIRS}")
endforeach()
 
set( LD_LIBRARIES "")
 
foreach( LD_FIND_COMPONENT ${LD_FIND_COMPONENTS} )
	set(
		LD${LD_FIND_COMPONENT}_LIBRARIES
		LD${LD_FIND_COMPONENT}
	)
	set( LD_LIBRARIES "${LD_LIBRARIES} LD${LD_FIND_COMPONENT}")
endforeach()

Problème résolu, le cache de Cmake me jouais un mauvais tour...

J'ai juste un dernier détail à régler :
J'arrive à obtenir les chemins vers les bibliothèques ainsi que les dossiers contenant les headers.
Par contre je n'arrive pas à obtenir les dossiers contenant les bibliothèques.
Est-ce vraiment utile de les chercher ou est-ce qu'on peut parfaitement faire sans ?

Pour ceux que cela pourrait intéresser :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
# All rights reserved
# Official Website : http://jsz.kegtux.org/
 
set(LD_FOUND 1)
 
message("Search ${LD_FIND_COMPONENTS} 's LastDungeon" )
 
set( LD_LIBRARY_DIRS "")
set( LD_LIBRARIES "")
 
foreach( LD_FIND_COMPONENT ${LD_FIND_COMPONENTS} )
	FIND_LIBRARY(
		LD${LD_FIND_COMPONENT}_LIBRARIES
		NAMES LD${LD_FIND_COMPONENT}
		HINTS ${BASE_HINTS}
		PATH_SUFFIXES LastDungeon lib lib64 .
		PATHS ${BASE_PATHS} C:/bin/ /usr/lib/
	)
	set(LD_TEMP_LIBRARY "${LD${LD_FIND_COMPONENT}_LIBRARIES}")
 
	STRING(COMPARE EQUAL "${LD_TEMP_LIBRARY}" "LD${LD_FIND_COMPONENT}_LIBRARIES-NOTFOUND" RESULT)
 
	if( ${RESULT} )
		message(ERROR " : Library LD${LD_FIND_COMPONENT} not found : ${LD_TEMP_LIBRARY}")
		set(LD_FOUND 0)
	else ()
		message("Library LD${LD_FIND_COMPONENT} found : ${LD_TEMP_LIBRARY}")
	endif()
 
	set( LD_LIBRARY_DIRS "${LD_LIBRARY_DIRS};${LD_TEMP_LIBRARY}" ) # problème, il faut le chemin du dossier ?
	set( LD${LD_FIND_COMPONENT}_LIBRARY_DIRS ${LD_TEMP_LIBRARY}) #idem
	message("test :" ${LD_LIBRARY_DIRS})
 
	#chemin des .so
	set( LD_LIBRARIES "${LD_LIBRARIES};${LD${LD_FIND_COMPONENT}_LIBRARIES}" )
 
endforeach()
 
set( LD_INCLUDE_DIRS "")
 
foreach( LD_FIND_COMPONENT ${LD_FIND_COMPONENTS} )
 
	FIND_PATH(
		LD${LD_FIND_COMPONENT}_INCLUDE_DIRS
		NAMES LastDungeon/${LD_FIND_COMPONENT}.h
		HINTS ${BASE_HINTS}
		PATH_SUFFIXES LastDungeon include .
		PATHS ${BASE_PATHS} C:/includes/ /usr/include/
	)
	set(LD_TEMP_INCLUDE_DIRS "${LD${LD_FIND_COMPONENT}_INCLUDE_DIRS}")
 
	STRING(COMPARE EQUAL "A${LD_TEMP_INCLUDE_DIRS}" "ALD${LD_FIND_COMPONENT}_INCLUDE_DIRS-NOTFOUND" RESULT)
 
	if( ${RESULT} )
		set(LD_FOUND 0)
		message(ERROR " : Header ${LD_FIND_COMPONENT}.h not found : ${LD_TEMP_INCLUDE_DIRS}")
	else ()
		message("Header ${LD_FIND_COMPONENT}.h found : ${LD_TEMP_INCLUDE_DIRS}")
	endif()
 
	set( LD_INCLUDE_DIRS "${LD_INCLUDE_DIRS} ${LD_TEMP_INCLUDE_DIRS}")
endforeach()
 
#set( LD_LIBRARIES "")
 
#foreach( LD_FIND_COMPONENT ${LD_FIND_COMPONENTS} )
#	set(
#		LD${LD_FIND_COMPONENT}_LIBRARIES
#		LD${LD_FIND_COMPONENT}
#	)
#	set( LD_LIBRARIES "${LD_LIBRARIES};LD${LD_FIND_COMPONENT}")
#endforeach()

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
cmake_minimum_required(VERSION 2.6)
 
project(LDDataBase)
 
set( CMAKE_MODULE_PATH ".;${CMAKE_MODULE_PATH}" )
 
find_package ( LD COMPONENTS erreur)
 
if( ${LD_FOUND} )
	MESSAGE( STATUS " Found LD" )
	#On peut continuer
else()
	#On ne continue pas
	MESSAGE( FATAL_ERROR " LD not Found" )
endif()
 
find_package( Boost 
 
        1.46.1
 
        REQUIRED system
)
 
set(LIBRARY_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})
 
file ( GLOB_RECURSE
 
        source_files
 
        ../src/* )
 
add_library(
 
        LDdatabase
 
        SHARED
 
        ${source_files}
 
)
 
set(CMAKE_CXX_FLAGS "-std=c++11")        ##We use C++11
 
include_directories(../include ${LD_INCLUDE_DIRS} {Boost_INCLUDE_DIRS} )
 
link_directories( ${LD_LIBRARY_DIRS} ${Boost_LIBRARY_DIRS} )
 
target_link_libraries( LDdatabase ${LD_LIBRARIES} ${Boost_LIBRARIES})

14/02/2013, 23h25
bretus

Bonsoir,

Citation:

Envoyé par Neckara

Par contre je n'arrive pas à obtenir les dossiers contenant les bibliothèques.
Est-ce vraiment utile de les chercher ou est-ce qu'on peut parfaitement faire sans ?

Sachant que find_library renvoie des chemins complets, tes utilisateurs n'auront pas besoin de faire des "link_directories" donc tu peux te passer de LD_LIBRARY_DIRS.

Ceci dit, tu pourrais les obtenir avec "get_filename_component".
15/02/2013, 06h58
Neckara
Citation:

Envoyé par bretus

Bonsoir,

Sachant que find_library renvoie des chemins complets, tes utilisateurs n'auront pas besoin de faire des "link_directories" donc tu peux te passer de LD_LIBRARY_DIRS.

Ceci dit, tu pourrais les obtenir avec "get_filename_component".

Merci, cela marche parfaitement avec
Code:

1 2 3 GET_FILENAME_COMPONENT(var $ {file} PATH )
.

Merci pour votre aide, je passe le sujet en résolu.

Fuseau horaire GMT +2. Il est actuellement 09h03.