c++ - tutorial - cmake visual studio 2017




Utilisation de CMake pour générer des fichiers de projet Visual Studio C++ (6)

Beaucoup de bonnes réponses ici mais elles pourraient être remplacées par ce support de CMake dans Visual Studio (5 Oct 2016)

Je travaille sur un projet C ++ open source, pour du code qui se compile sous Linux et Windows. J'utilise CMake pour construire le code sur Linux. Pour des raisons de facilité de développement et pour des raisons politiques, je dois m'en tenir aux fichiers / éditeurs de projets Visual Studio sous Windows (je ne peux pas passer à Code::Blocks , par exemple). Je vois des instructions pour générer des fichiers Visual Studio en utilisant CMake, comme here .

Avez-vous utilisé CMake pour générer des fichiers Visual Studio avant? Comment a été votre expérience? Supposons que je souhaite ajouter un nouveau fichier à mon projet. Quel est le flux de travail pour cela?


CMake peut générer de très beaux .projs / .slns Visual Studio, mais il y a toujours le problème avec le besoin de modifier les fichiers .cmake plutôt que .proj / .sln . Comme c'est le cas maintenant, nous le traitons comme suit:

  1. Tous les fichiers sources vont dans /src et les fichiers visibles dans Visual Studio ne sont que des "liens" vers eux définis dans .filter .
  2. Le programmeur ajoute / supprime des fichiers en se souvenant de travailler sur le répertoire /src défini, pas celui du projet par défaut.
  3. Quand il a fini, il lance un script qui "actualise" les fichiers .cmake respectifs.
  4. Il vérifie si le code peut être construit dans l'environnement recréé.
  5. Il commet le code.

Au début, nous avions un peu peur de la façon dont cela se passera, mais le workflow fonctionne très bien et avec un joli diff visible avant chaque commit, tout le monde peut facilement voir si ses changements ont été correctement mappés dans les fichiers .cmake .

Une autre chose importante à savoir est le manque de support ( afaik ) pour "Configurations de solutions" dans CMake. En l'état, vous devez générer deux répertoires avec des projets / solutions - un pour chaque type de construction (déboguer, libérer, etc.). Il n'y a pas de support direct pour des fonctionnalités plus sophistiquées - en d'autres termes: la commutation entre les configurations ne vous donnera pas ce que vous pourriez attendre.


Comme le dit Alex, ça fonctionne très bien. La seule difficulté consiste à se souvenir de faire des changements dans les fichiers cmake, plutôt que dans Visual Studio. Ainsi, sur toutes les plates-formes, le flux de travail est similaire à si vous aviez utilisé des anciens makefiles.

Mais il est assez facile de travailler avec, et je n'ai eu aucun problème avec cmake générant des fichiers invalides ou quelque chose comme ça, donc je ne m'inquiéterais pas trop.


J'ai démarré mon propre projet, appelé syncProj. Documentation / liens de téléchargement d'ici:

https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit# https://sourceforge.net/projects/syncproj/

Si vous envisagez d'utiliser Visual Studio pour le développement, seul le format C ++ est actuellement pris en charge.

Le principal avantage par rapport aux autres systèmes make est que vous pouvez réellement déboguer votre script, car il est basé sur C #.

Si vous n'êtes pas familier avec syncProj, vous pouvez simplement convertir votre solution / projet en script .cs, et poursuivre le développement à partir de ce point.

Dans cmake vous aurez besoin d'écrire tout à partir de zéro.


Nous avons déplacé la chaîne de construction de notre département à CMake, et nous avons eu quelques obstacles internes puisque d'autres départements utilisaient nos fichiers de projet et étaient habitués à les importer dans leurs solutions. Nous avons également eu des plaintes à propos de CMake n'étant pas complètement intégré dans le gestionnaire de projet / solution Visual Studio, les fichiers ont donc 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, c'était une transition assez douce. Nous sommes très heureux car nous n'avons plus à traiter avec des fichiers de projet.

Le workflow concret pour ajouter un nouveau fichier à un projet est vraiment simple:

  1. Créez le fichier, assurez-vous qu'il est au bon endroit.
  2. Ajoutez le fichier à CMakeLists.txt.
  3. Construire.

CMake 2.6 se réexécute automatiquement si tous les fichiers CMakeLists.txt ont changé (et (semi-) recharge automatiquement la solution / les projets).

Souvenez-vous que si vous réalisez des générations hors source, vous devez veiller à ne pas créer le fichier source dans le répertoire de construction (puisque Visual Studio ne connaît que le répertoire de construction).


CMake est vraiment très bon pour ça. La partie clé était que tout le monde du côté Windows doit se souvenir de lancer CMake avant de le charger dans la solution, et tout le monde du côté de Mac devrait se souvenir de l'exécuter avant make.

Le plus dur était en tant que développeur Windows en s'assurant que vos changements structurels étaient dans le fichier cmakelist.txt et non dans les fichiers de solution ou de projet car ces changements seraient probablement perdus et même s'ils ne seraient pas perdus ne seraient pas transférés au Mac. aussi 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 une intégration continue des deux côtés, ceux-ci seront éteints tôt, et les gens finiront par prendre l'habitude.





cmake