Utilisation de CMake pour générer des fichiers de projet Visual Studio C++
Je travaille sur un projet C++ open source, pour un code compilé sous Linux et Windows. J'utilise CMake pour compiler le code sous Linux. Pour faciliter la configuration du développement et pour des raisons politiques, je dois m'en tenir aux fichiers de projet/éditeur Visual Studio sous Windows (je ne peux pas basculer sur Code :: Blocks , par exemple). Je vois des instructions pour générer des fichiers Visual Studio en utilisant CMake, comme ici .
Avez-vous déjà utilisé CMake pour générer des fichiers Visual Studio? Comment a été votre expérience? Supposons que je veuille ajouter un nouveau fichier à mon projet. Quel est le flux de travail pour cela?
CMake est en fait assez bon pour cela. La partie clé était que tout le monde sous Windows devait se rappeler d’exécuter CMake avant de charger la solution, et tout notre côté Mac devait se rappeler de l’exécuter avant de make.
La partie la plus difficile a été en tant que développeur Windows, en vous assurant que vos modifications structurelles étaient dans le fichier cmakelist.txt et non dans les fichiers de solution ou de projet, car ces modifications seraient probablement perdues et même si elles ne l'étaient pas, elles ne seraient pas transférées du côté Mac. également besoin d’eux, et les gars de Mac devraient se rappeler de ne pas modifier le fichier make pour les mêmes raisons.
Cela demande juste un peu de réflexion et de patience, mais il y aura des erreurs au début. Mais si vous utilisez intégration continue des deux côtés, ils seront rapidement supprimés et les gens finiront par prendre l'habitude.
Je ne sais pas si c'est directement lié à la question, mais je cherchais une réponse sur la façon de générer * .sln à partir de projets cmake. J'ai découvert qu'on pouvait utiliser quelque chose comme ceci:
cmake -G "Visual Studio 10"
L'exemple génère les fichiers VS 2010 nécessaires à partir d'un fichier CMakeLists.txt en entrée.
Nous avons transféré la chaîne de construction de notre département à CMake et nous avons eu quelques difficultés internes depuis d’autres départements qui utilisaient nos fichiers de projet et s’habituaient à les importer dans leurs solutions. Nous nous sommes également plaints du fait que CMake n’était pas complètement intégré au gestionnaire de projets/solutions de Visual Studio. Par conséquent, les fichiers ont dû être ajoutés manuellement à CMakeLists.txt; C'était une rupture majeure dans le flux de travail auquel les gens étaient habitués.
Mais en général, la transition s’est faite en douceur. Nous sommes très heureux car nous n’avons plus à traiter de dossiers de projets.
Le processus concret permettant d'ajouter un nouveau fichier à un projet est très simple:
- Créez le fichier, assurez-vous qu'il est au bon endroit.
- Ajoutez le fichier à CMakeLists.txt.
- Construire.
CMake 2.6 se ré-exécute automatiquement si des fichiers CMakeLists.txt ont été modifiés (et rechargent (semi-) automatiquement la solution/les projets).
N'oubliez pas que si vous construisez des constructions hors source, vous devez faire attention à ne pas créer le fichier source dans le répertoire de construction (car Visual Studio ne connaît que le répertoire de construction).
Comme Alex dit, ça marche très bien. Le seul problème est de ne pas oublier d’apporter des modifications aux fichiers cmake plutôt qu’à partir de Visual Studio. Ainsi, sur toutes les plates-formes, le flux de travail est similaire à celui utilisé si vous utilisiez de vieux fichiers Makefiles.
Mais il est assez facile de travailler avec, et je n'ai eu aucun problème avec la génération de fichiers invalides ou quoi que ce soit du genre avec cmake, donc je ne m'inquiéterais pas trop.
CMake peut générer vraiment de jolis Visual Studio .projs/.slns, mais le problème réside toujours dans la nécessité de modifier les fichiers .cmake au lieu de .proj/.sln. Dans l'état actuel des choses, nous traitons le problème comme suit:
- Tous les fichiers source vont à
/srcet les fichiers visibles dans Visual Studio ne sont que des "liens" menant à eux définis dans.filter. - Le programmeur ajoute/supprime les fichiers en gardant à l'esprit de travailler sur le répertoire
/srcdéfini, et non sur celui du projet par défaut. - Une fois terminé, il exécute un script qui "rafraîchit" les fichiers
.cmakerespectifs. - Il vérifie si le code peut être construit dans l'environnement recréé.
- Il commet le code.
Au début, nous avions un peu peur de la suite, mais le flux de travail fonctionne vraiment bien et avec le diff Nice visible avant chaque commit, tout le monde peut facilement voir si ses modifications ont été correctement mappées dans des fichiers .cmake.
Une autre chose importante à connaître est le manque de support ( autant que je sache ) pour les "Configurations de solutions" dans CMake. En l'état, vous devez générer deux Répertoires avec projets/solutions - un pour chaque type de construction (débogage, édition, etc.). Il n’existe pas de support direct pour des fonctionnalités plus sophistiquées - en d’autres termes: le passage d’une configuration à l’autre ne vous donnera pas ce que vous attendez.
CMake produit des projets et des solutions Visual Studio de manière transparente. Vous pouvez même créer des projets/solutions pour différentes versions de Visual Studio sans apporter de modification aux fichiers CMake.
Ajouter et supprimer des fichiers sources consiste simplement à modifier le CMakeLists.txt contenant la liste des fichiers sources et à régénérer les projets/solutions. Il existe même une fonction Globbing permettant de rechercher toutes les sources d'un répertoire (même si elle doit être utilisée avec prudence).
Le lien suivant explique très bien le comportement spécifique de CMake et de Visual Studio.
Beaucoup de bonnes réponses ici mais elles pourraient être remplacées par ceci Support de CMake dans Visual Studio (5 oct 2016)