Utilisation de Makefile au lieu des fichiers Solution/Projet sous Visual Studio (2005)

Question

Quelqu'un a-t-il de l'expérience dans l'utilisation de makefiles pour les builds Visual Studio C++ (sous VS 2005) par opposition à l'utilisation de la configuration du projet/solution.Pour nous, la façon dont fonctionnent le projet/les solutions n'est pas intuitive et conduit à une explosion de la configuration lorsque vous essayez de modifier les builds avec des indicateurs de compilation spécifiques.

Sous Unix, il est assez facile de configurer un makefile dont les options par défaut sont remplacées par les paramètres utilisateur (ou un autre paramètre de configuration).Mais faire ce genre de choses semble difficile dans Visual Studio.

À titre d'exemple, nous avons un projet qui doit être construit pour 3 plates-formes différentes.Chaque plateforme peut avoir plusieurs configurations (par exemple débogage, version et plusieurs autres).L'un de mes objectifs sur un projet nouvellement formé est d'avoir une solution permettant à toutes les plates-formes de vivre ensemble, ce qui facilite la création et le test des modifications de code puisque vous n'avez pas besoin d'ouvrir 3 solutions différentes juste pour tester votre code.Mais Visual Studio nécessitera 3 * (nombre de configurations de base) configurations.c'est à dire.Débogage PC, débogage X360, débogage PS3, etc.

Il semble qu'une solution makefile soit bien meilleure ici.Enveloppé avec quelques fichiers batch ou scripts de base, il serait facile de limiter l'exploration de la configuration au minimum et de ne conserver qu'un petit ensemble de fichiers pour toutes les différentes versions que nous devons réaliser.

Cependant, je n'ai aucune expérience avec les makefiles sous Visual Studio et j'aimerais savoir si d'autres ont des expériences ou des problèmes qu'ils peuvent partager.

Merci.

(article édité pour mentionner qu'il s'agit de versions C++)

Answer 1

J'ai trouvé certains avantages aux makefiles avec des projets volumineux, principalement liés à l'unification de l'emplacement des paramètres du projet.Il est un peu plus facile de gérer la liste des fichiers sources, d'inclure les chemins, les définitions du préprocesseur, etc., s'ils se trouvent tous dans un makefile ou un autre fichier de configuration de build.Avec plusieurs configurations, l'ajout d'un chemin d'inclusion signifie que vous devez vous assurer de mettre à jour chaque configuration manuellement via les propriétés de projet délicates de Visual Studio, ce qui peut devenir assez fastidieux à mesure qu'un projet grandit.

Les projets qui utilisent de nombreux outils de construction personnalisés peuvent également être plus faciles à gérer, par exemple si vous devez compiler des pixel/vertex shaders ou coder dans d'autres langages sans prise en charge native de VS.

Cependant, vous aurez toujours besoin de différentes configurations de projet, car vous devrez différencier l'invocation de l'outil de construction pour chaque configuration (par ex.en passant différentes options de ligne de commande à créer).

Inconvénients immédiats qui me viennent à l’esprit :

• Constructions plus lentes :VS n'est pas particulièrement rapide à appeler des outils externes, ni même à déterminer s'il doit créer un projet en premier lieu.
• Dépendances inter-projets gênantes :C'est délicat à configurer pour qu'un dépendant provoque la construction du projet de base, et plus compliqué à s'assurer qu'il est construit dans le bon ordre.J'ai réussi à convaincre les SCons de faire cela, mais c'est toujours un défi de bien travailler.
• Perte de certaines fonctionnalités utiles de l'EDI :Edit & Continue étant le principal !

En bref, vous passerez moins de temps à gérer les configurations de votre projet, mais plus de temps à convaincre Visual Studio de fonctionner correctement avec celui-ci.

Answer 2

Visual Studio est construit au-dessus du MSBuild fichiers de configuration.Vous pouvez considérer les fichiers *proj et *sln comme des makefiles.Ils vous permettent de personnaliser entièrement le processus de construction.

Answer 3

Bien que cela soit techniquement possible, ce n'est pas une solution très conviviale dans Visual Studio.Il vous combattra tout le temps.

Je vous recommande d'y jeter un oeil NANT.Il s'agit d'un système de construction très robuste dans lequel vous pouvez faire pratiquement tout ce dont vous avez besoin.

Notre script NAnt fait cela à chaque build :

1. Migrer la base de données vers la dernière version
2. Générer des entités C# hors de la base de données
3. Compilez chaque projet dans notre solution "maître"
4. Exécutez tous les tests unitaires
5. Exécutez tous les tests d’intégration

De plus, notre serveur de build exploite cela et ajoute 1 tâche supplémentaire, qui génère la documentation Sandcastle.

Si vous n'aimez pas XML, vous pouvez également jeter un œil à Râteau (rubis), Cuire/BooBuildSystem (Bouh), ou Psaké (PowerShell)

Answer 4

Vous pouvez utiliser Nant pour construire les projets individuellement, remplaçant ainsi la solution et avoir 1 solution de codage et aucune solution de construction.

Une chose à garder à l'esprit est que la solution et les fichiers csproj à partir de 2005 sont des scripts msbuild.Donc, si vous vous familiarisez avec msbuild, vous pourrez peut-être utiliser les fichiers existants, pour faciliter vs et faciliter votre déploiement.

Answer 5

Nous avons une configuration similaire à celle que vous décrivez.Nous prenons en charge au moins 3 plates-formes différentes, nous avons donc constaté qu'en utilisant CMake pour gérer les différentes solutions Visual Studio.La configuration peut être un peu pénible, mais cela se résume à la lecture de la documentation et de quelques didacticiels.Vous devriez pouvoir faire pratiquement tout ce que vous pouvez faire en accédant aux propriétés des projets et de la solution.Je ne sais pas si vous pouvez faire vivre ensemble les trois plates-formes dans la même solution, mais vous pouvez utiliser Régulateur de vitesse pour prendre soin de vos builds et exécuter vos scripts de test aussi souvent que nécessaire.