Utilisation de cmake pour générer des fichiers de projet Visual Studio C ++

Question

Je suis en train de travailler sur un open source, C++, pour le code qui compile sous Linux et Windows. J'utilise cmake pour générer le code sur Linux. Pour la facilité de dev-installation et pour des raisons politiques, je dois en tenir à des fichiers projet visual studio/éditeur sur Windows (je ne peux pas passer à Code::Blocks, par exemple). - Je voir les instructions pour générer visual studio fichiers en utilisant cmake, comme ici.

Avez-vous utilisé cmake pour générer visual studio fichiers avant? Comment a été votre expérience? Supposons que je veux ajouter un nouveau fichier de mon projet. Qu'est-ce que le flux de travail pour cela?

Answer 1

cmake est en fait assez bon pour cela, la clé de la partie tout le monde était du côté de windows a à retenir de lancer cmake avant de les charger dans la solution, et tout le monde de notre côté mac aurait à retenir pour l'exécuter avant de le faire. La partie la plus difficile a été en tant que développeur windows vous assurer que vos modifications structurelles ont été dans le cmakelist.txt fichier et non pas dans la solution ou les fichiers de projet que ces changements seraient probablement perdus et même si c'est pas perdu serait pas transféré sur le côté mac qui a aussi besoin d'eux, et le Mac gars aurait besoin de se rappeler de ne pas modifier le fichier de créer pour les mêmes raisons. Il faut juste un peu de réflexion et de patience, mais il y aura des erreurs au début. Mais si vous utilisez de l'intégration continue sur les deux côtés de ces obtiendrez a secoué tôt et les gens finiront par avoir l'habitude.

Answer 2

Je ne suis pas sûr que cela soit 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.

Answer 3

Nous avons déménagé notre département de construction de la chaîne de CMake, et nous avons eu quelques internes roadbumps depuis d'autres départements où l'utilisation de nos fichiers de projet et où les habitués à juste de les importer dans leurs solutions. Nous avons également eu quelques plaintes au sujet de CMake ne pas être pleinement intégrées dans le projet Visual Studio/solution manager, de sorte que les fichiers ont dû être ajoutés manuellement à CMakeLists.txt; c'était une rupture majeure dans le flux de travail les gens y sont habitués.

Mais en général, c'était assez transition en douceur. Nous sommes très heureux car nous n'avons pas à traiter avec les fichiers de projet plus.

Le béton de flux de travail pour ajouter un nouveau fichier à un projet est très simple:

1. Créer le fichier, assurez-vous qu'il est dans le bon endroit.
2. Ajouter le fichier à CMakeLists.txt.
3. Construire.

CMake 2.6 automatiquement les rediffusions si tous les CMakeLists.txt les fichiers ont été modifiés (et (semi-)automatiquement la recharge de la solution/projets).

N'oubliez pas que si vous êtes en train de faire out-of-source construit, vous devez être prudent de ne pas créer le fichier source dans le répertoire de construction (depuis Visual Studio ne sait que sur le répertoire de construction).

Answer 4

Comme Alex dit, ça marche très bien. La seule difficulté est de ne pas oublier de modifier les fichiers cmake plutôt que de Visual Studio. Ainsi, sur toutes les plates-formes, le flux de travail est similaire à celui utilisé si vous utilisiez de vieux fichiers Make.

Mais il est assez facile de travailler avec, et cmake n'a généré aucun problème pour générer des fichiers invalides ou quelque chose du genre, je ne m'inquiéterais donc pas trop.

Answer 5

CMake peut générer de très belle Visual Studio .projs/.slns, mais il y a toujours le problème avec la nécessité de modifier l' .cmake plutôt que des fichiers .proj/.sln. Comme il est maintenant, nous le faisons comme suit:

1. Tous les fichiers source d'aller à l' /src et fichiers visibles dans Visual Studio sont juste des "liens" vers définis en .filter.
2. Programmeur ajoute/supprime les fichiers en se souvenant de travail sur l'définis /src annuaire, pas la valeur par défaut du projet.
3. Quand il est fait, il exécuter un script qui "actualise" le .cmake fichiers.
4. Il vérifie si le code peut être intégré dans l'ambiance recréée.
5. Il s'engage le code.

Au début, nous avions un peu peur de comment il va tourner, mais le flux de travail fonctionne vraiment bien et avec une belle diff visible avant chaque commit, tout le monde peut facilement voir si ses modifications ont été correctement mappé en .cmake fichiers.

Une chose plus importante à connaître est le manque de soutien (autant que je sache) pour la Solution "Configurations" dans CMake. Comme il est, vous devez générer des deux répertoires avec des projets/solutions - un pour chaque type de build (debug, release, etc.). Il n'y a pas de support direct pour plus de fonctionnalités sophistiquées - en d'autres termes: la commutation entre les configurations ne vais pas vous donner ce que vous pourriez attendre.