Je suis impliqué dans le projet C ++ ciblé pour les plates-formes Windows et Linux (RHEL). Jusqu'à présent, le développement a été purement effectué sur Visual Studio 2008. Pour la compilation Linux, nous avons utilisé le plug-in 3e Party Visual Studio, qui lisent des fichiers VS Solution / Perojects et compilé à distance sur la machine Linux.
Récemment, la décision était d'abandonner le plugin tiers.
Maintenant, ma grosse préoccupation est un système de construction. Je cherchais autour de vous pour des outils de construction croisés croisés. De cette façon, je n'ai pas besoin de maintenir deux séries de fichiers de construction (par exemple VCProj / Solution pour Windows et définissez des fichiers pour Linux).
J'ai trouvé les candidats suivants: une. Faire des scons b. CMAKE
Que pensez-vous des outils de développement croisé de la plate-forme?
Encore un autre point qui me dérange est que Visual Studio (+ Visual Assist) perdra une fonctionnalité beaucoup sans fichiers VCPROJ - comment vous gérez le problème avec les outils?
merci DIMA
PS 1: quelque chose que j'aime sur Scons, c'est qu'il (a) utilise Python et, par conséquent, il est flexible, tandis que Cmake utilise la langue de propriété (je comprends que ce n'est pas une fonctionnalité gagnante pour un système de construction) (B) autonome (pas besoin de générer des fichiers de fabrication de Linux comme avec cmake).
Alors pourquoi pas des scons? Pourquoi dans vos projets, la décision était d'utiliser CMAKE?
6 Réponses :
CUKE vous permettra de toujours utiliser des solutions Visual Studio et des fichiers de projet. Cmake ne construit pas le code source lui-même, mais il a généré des fichiers de construction pour vous. Pour Linux, cela peut être Code :: Blocs, Kdevelop ou Makefiles unis ou encore d'autres choix ésotériques. Pour les fenêtres, il peut s'agir d'autres fichiers de projet Visual Studio et d'autres d'autres pour les macos. So Visual Studio Solutions et projets sont créés à partir de votre CMAKELIST.TXT. Cela fonctionne pour de grands projets tout simplement bien. Par exemple. Actuelle Ogre3D utilise Cmake pour toutes les plateformes (Windows, Linux, MacOS et iPhone) et cela fonctionne vraiment bien.
Je ne sais pas grand chose sur les scênes à cet égard cependant, je n'ai utilisé que pour créer une bibliothèque et seulement sous Linux. Je ne peux donc pas comparer ces deux sur un terrain équitable. Mais pour nos projets multi-plateformes, la cmake est assez fort.
Cmake est assez bon - il sera Régénérer les fichiers de projet VS, il est donc partiellement trompeur de dire "Permet d'utiliser encore des fichiers de projet". Je le recommande vivement pour un projet C ++, comme la seule solution si l'on veut nécessiter une compatibilité entre de nombreux OS qui incluent Windows (Windows est le seul "difficile" ...), et où vous souhaitez également utiliser Visual Studio.
J'espère que le reste de ma réponse s'éclaircit. :) Tu as raison bien sûr. Les fichiers de solution que vous avez maintenant sont remplacés par ceux générés. Cmake ajoutera quelques projets à votre solution elle-même (all_projects, installez-vous, zero_check) ces éléments peuvent se sentir maladroit au début, mais sont plutôt pratiques une fois que vous vous envenez ce qu'ils sont. Particulièrement installer. Il construira toutes les parties de la solution et copiera des dlls, des exes et d'autres fichiers créés, comme spécifié dans le CMAKFiles.txt sur leurs DIRS cible afin que vous puissiez simplement exécuter des SNS ou un autre outil de package pour créer un package d'installation.
Il convient de noter que Scons peut générer des fichiers de projet VS.
Je n'ai pas utilisé des scênes avant, alors ne pouvez pas dire comment cela fonctionne, mais Cmake fonctionne assez bien.
Cela fonctionne en produisant les fichiers de construction nécessaires à la plate-forme que vous ciblez.
Lorsqu'il est utilisé pour cibler VC ++, il produit des fichiers de solution et de projet, ainsi de VS, il apparaît comme s'il s'agissait de projets vs natifs. Bien entendu, la seule différence est que si vous éditez le projet ou la solution directement via VS, les modifications seront effacées à la prochaine exécution de la cmake, car elle écrase vos fichiers de projet / solution.
Donc, toute modification doit plutôt être apportée aux fichiers cmake.
a dû le faire beaucoup dans le passé. Ce que nous avons fait, c'est utiliser GNU FAIT pour pratiquement tout, y compris Windows, parfois.
Vous pouvez utiliser les fichiers de projet sous Windows si vous préférez et utilisez GNU Cake pour Linux.
Il n'y a pas vraiment une bonne façon d'écrire des fichiers de plate-forme croix car le fichier cible sera être différent entre autres (et problèmes de pathername, \ vs / etc). En général, vous serez probablement modifier le code sur les différentes plates-formes pour prendre en compte les différences subtiles, de sorte qu'un fichier à créer un fichier et la vérification des autres plates-formes devrait se produire. de toute façon.
De nombreux projets de système d'exploitation gèrent des fabricants de fabricants pour différentes plates-formes telles que ZLIB où elles sont nommées comme Makefile.win, Makefile.Linux, etc., vous pourriez suivre leur tête.
Quel est l'avantage en utilisant quelque chose comme Cmake avec votre approche? Avec Clake, vous devez uniquement gérer un ensemble de fichiers de construction et peut toujours utiliser votre IDE préféré en plein avantage.
Un avantage est qu'il peut être plus facile d'utiliser les scripts standard pour chaque système plutôt que de déterminer un seul script de plate-forme transversale qui ne fonctionne que dans tous les bizarreries pour tous les systèmes d'exploitation. Toujours beaucoup d'effort de duplication, bien que ...
Nous avons un grand nombre de bibliothèques et d'applications principales basées sur ces bibliothèques. Nous maintenons un système de construction basé sur Makefile sur Linux et sous Windows à l'aide de la solution Visual Studio pour chaque projet ou bibliothèque.
Nous trouvons que cela fonctionne bien pour nos besoins, chaque bibliothèque ou application est développée sous Linux ou Windows avec la compilation croisée dans l'esprit (par exemple, n'utilisez pas d'API spécifique à la plate-forme). Nous utilisons Boost pour des trucs comme des chemins de fichiers, des threads et ainsi de suite. Dans des cas spécifiques, nous utilisons des modèles / # définit pour sélectionner une solution spécifique à la plate-forme (par exemple des événements). Quand est prêt, nous passons à l'autre système (Linux ou Windows), recompiler, réparer des avertissements / erreurs et test.
au lieu de passer du temps à comprendre les outils pouvant traverser la compilation des deux plates-formes que nous utilisons le système qui convient le mieux à chaque plate-forme et de passer du temps à réparer des problèmes spécifiques et à améliorer le logiciel.
Nous avons des applications d'interface graphique uniquement sur Windows ATM. Donc, il n'y a pas d'interface graphique pour croiser. La majeure partie de notre développement partagé entre Windows et Linux est la mise en réseau latéral du serveur (sockets, TCP / IP, UDP ...), puis des outils latéraux du client sur les applications Linux et GUI sous Windows.
Utiliser avec perforce pour la gestion de la version de code source Nous trouvons dans de nombreux cas que le système de fabrication de makefile Linux est beaucoup plus flexible pour ce dont nous avons besoin alors de Windows vs. Surtout pour l'utilisation de plusieurs espaces de travail (vues des versions de code source) où nous devons indiquer des annuaires courants et ainsi de suite. Sur Linux, cela peut être effectué automatiquement d'exécuter un script pour mettre à jour les variables d'environnement, sur Visual Studio Référencissement des variables d'environnement, il est très inflexible car il est difficile de mettre à jour automatiquement entre des vues / des branches.
re Sync Question:
Je suppose que vous vous demandez comment vous assurer que les deux systèmes de construction sont synchronisés entre Linux et Windows. Nous utilisons effectivement Hudson sur Linux et Cruisecontrol sous Windows (nous avions d'abord Windows avec Cruise Control, lorsque je suis allé à la configuration de la version Linux, j'ai pensé que Hudson est préférable, donc maintenant nous avons un environnement mixte). Nos systèmes fonctionnent tout le temps. Lorsque quelque chose est mis à jour, il est testé et publié (version Windows ou Linux) afin que vous sachiez tout de suite si cela ne fonctionne pas. Pendant le test, nous nous assurons que toutes les dernières fonctionnalités sont présentes et entièrement fonctionnelles. Je suppose que c'est tout, pas de magie sombre impliquée.
OH Vous voulez dire des scripts de construction ... Chaque application a sa propre solution, dans la solution que vous configurez des dépendances. Sur le côté Linux, j'ai un maquefile pour chaque projet et un script de construction dans le répertoire de projet qui prend soin de toutes les dépendances, cela signifie principalement construire des bibliothèques principales et un couple de cadres spécifiques requis pour l'application donnée. Comme vous pouvez le constater, cela est différent pour chaque plate-forme, il est facile d'ajouter une ligne pour créer un script qui modifie le répertoire et apporte le projet requis.
Il aide à avoir une configuration de projets de manière cohérente.
sur Windows Vous ouvrez le projet et ajoutez un projet de dépendance. Encore aucune magie impliquée. Je vois ce type de tâches comme le développement du développement, par exemple, vous avez ajouté de nouvelles fonctionnalités à un projet et devez relier les cadres et les en-têtes. Donc, de mon point de vue, aucune raison de l'automatiser - car ils font partie de ce que les développeurs font lorsqu'ils mettent en œuvre des fonctionnalités.
Je voterai si vous dites comment vous assurez que les différents scripts de construction ne sortent pas de la synchronisation. (Un serveur d'intégration continue serait d'une manière)
Voici un Article sur la décision prise par les développeurs de KDE à choisir CMAKE sur Scons. Cependant, je dois indiquer que cet article a presque trois ans, alors les scons devraient être améliorés.
ici est comparativant des SCONS avec d'autres outils de construction.
Notez également que Scons est plus générique, tandis que Cmake est biaisé vers des langues particulières.
Une autre option est mabrake. C'est comme une cmake dans laquelle il génère des solutions à partir de fichiers de définition. Il est open source et la dernière version est très hautement personnalisable à l'aide de scripts Lua. Nous avons pu ajouter un support de plate-forme personnalisé sans trop de problèmes. Pour votre situation, elle prend en charge la norme Visual Studio et GNU Makefiles.
voir Premake 4.0 Page d'accueil
Cruisecontrol est un bon choix pour une intégration continue. Nous devons courir sur Linux en utilisant mono avec succès.
Je ne recommanderais pas Premake Premake en raison du manque de popularité / de communauté / de soutien par rapport à la cmake et aux scêpes qui sont utilisés avec plusieurs projets majeurs.
Le système OUT est destiné au maximum de deux plates-formes, de sorte que la question est de savoir si la cmake n'est pas "sur tuant"? Un autre point que je suis préoccupé est que la construction doit être reproductible (bâtiment deux fois à partir de zéro donnera exactement les produits les mêmes ). Bien sûr, utiliser le système de construction natif, je suis proche de la cible. Est-il possible de cumaker le cumake et créera des vcProj / Makefiles différents selon le réglage de la personne la compilant (par exemple pour Windows chaque développeur do compilation sur sa machine privée)?
Juste à une note sur l'assistance visuelle. Il a une option pour charger des fichiers de répertoire lors de l'utilisation de solutions vides.