7
votes

Mise en route avec un projet Cross Platform C ++

Je démarre un projet C ++ que j'aimerais compiler de manière égale à Eclipse (Linux) et à VS2010 du même référentiel et pourrait utiliser une aide d'aide à démarrer. Bien que de nombreux aspects puissent être de google individuellement, j'espérais avoir des conseils sur la manière de contacter le problème dans un ensemble.

Par exemple, où conserver les sources de la bibliothèque, comment structurer le fichier de fabrication et comment intégrer Googletest (Trouver un didacticiel novice sur Googletest Seul est difficile). Un lien vers un didacticiel qui répond à ces aspects serait formidable ou une série de tutoriels qui pourraient aider ensemble.

Mon arrière-plan est en C # et j'essaie de maintenir la "propreté" et l'organisation de mes projets VS.


2 commentaires

Voulez-vous dire compatibilité entre VS2010 sur Windows et Eclipse sur Linux? Eclipse est elle-même une IDE très multi-plateformes.


Oui, merci de demander. Eclipse fonctionne sur Linux (openseuse 11.3)


3 Réponses :


4
votes

Une chose que je pourrais vous suggérer si vous allez fortement plate-forme et que vous souhaitez que tout soit aussi «propre» possible: Centralisez votre système de construction avec un outil de construction multiplate-forme moderne comme des scons. Il est écrit en Python, c'est assez concis et puissant, et ça marche partout.

ou, si vous êtes un fan d'Eclipse, installez simplement Eclipse sur Windows et GNU / Linux. Comme je l'ai mentionné ci-dessus, c'est une plate-forme croisée et vous pouvez le faire fonctionner pour les compilateurs sur toutes sortes de systèmes différents.


5 commentaires

Il semble prometteur, mais à quel point il sera difficile de mettre en œuvre? Je viens de m'envelopper autour de faire


À mon humble avis, faire la syntaxe est terriblement hacky. Si vous lisez à propos de son histoire, il n'a jamais été vraiment destiné à être une solution publique publique à grande échelle. Il est difficile à mettre à l'échelle, difficile à maintenir et à assurer une perspicacité humaine. Il suffit de regarder le nombre d'outils qui pile obfuscation sur l'obfuscation (automake et leurs parents). D'autre part, Scons est simplement python et il est bien documenté avec beaucoup d'exemples.


@CCOOK: Scons est beaucoup plus automatisé et que vous avez la pleine puissance de Python, vous pouvez utiliser glob.glob et os.listdir pour obtenir la liste des fichiers dans Un répertoire, évitant ainsi de maintenir la liste des fichiers ...


@Matthieu M. M. Souhaitez-vous toujours la mettre aussi un avantage si je ne connaissais pas Python?


@CCOOK: J'ai appris Python pendant la migration de ma demande de faire à Scons;) La documentation Python est d'une excellente qualité et c'est une langue généralisée qui signifie que la plupart des questions que vous aurez déjà été répondues sur un forum ou un site de questions et réponses et Google trouvera eux pour vous.



5
votes

Vous voudrez regarder CMAKE .


0 commentaires

13
votes

J'ai fait des projets multiples multiples qui utilisaient les systèmes de construction "natifs" sur les deux plates-formes (fichiers VSPROJ sous Windows et MakeFiles sous Linux), mais il s'agissait d'une douleur à la maintenance des deux fichiers de projet. Donc, oui, je suis d'accord avec les autres suggestions que vous devriez essayer de commencer avec un utilitaire de construction de plate-forme croix solide. Cmake ou éventuellement Boost Build semble être des options décentes - probablement il y en a beaucoup d'autres .

En ce qui concerne les bibliothèques tierces, vous voudrez coller à des trucs qui est une plate-forme transversale solidement testée. Boost est la meilleure bibliothèque à usage général de C ++ (oui, vous le voyez mentionné ici à peu près tous les C ++ Fil ... Mais c'est parce que c'est vraiment est une belle collection de choses utiles). Quant à XML, http, image libs, interface utilisateur - il y a toutes les bonnes options de la plate-forme croisée - il suffit de regarder autour de vous ou de demander ici si vous avez des exigences spécifiques. Quoi que vous fassiez, n'utilisez pas de bibliothèque à partir de CodeProject ou d'un autre site orienté MS qui n'a été testé qu'avec Visual Studio 6 - cela mènera simplement à la misère. La plupart des libs GNU construisent des fenêtres ces jours-ci, vous devriez donc être raisonnablement en sécurité avec ce genre de choses.

Bien que cela soit tentant, essayez de minimiser la plate-forme #Ifdefs dans votre code - préférez plutôt de résumer n'importe quelle plate-forme spécifique spécifique dans une bibliothèque autant que possible.

bonne chance!


7 commentaires

En ce qui concerne #Ifdef S vs. Séparer les bibliothèques - Il n'est pas déraisonnable de mettre du code commun dans une classe de base dans une bibliothèque, puis étendez cette classe à séparer les classes d'enfants spécifiques à la plate-forme qui varient d'un comportement spécifique à la plate-forme en utilisant polymorphisme. Ensuite, le seul #Ifdef s requis doit gouverner quelle classe enfant est utilisée.


En ce qui concerne les bibliothèques IFDEF / SPART, vous pouvez également avoir un fichier d'en-tête commun, puis diviser les fichiers source avec une partie de la source dans un CPP partagé et une partie de la source des fichiers spécifiques à la plate-forme qui ne sont que sur le système approprié.


Les bibliothèques sont open source; Devrais-je simplement les compiler localement dans le cadre du processus de construction et laisser les fichiers binaires du référentiel? Merci


J'ai trouvé une belle Boost Build intro: highscore.de/cpp/boostbuild semble vraiment bon


@CCOOK - Oui, je vous recommanderais de construire votre tierce partie libs sur un système de fichiers partagé fiable (Samba exécutant sur Linux fonctionne parfaitement pour cela, mais tout système de fichiers réseau moderne ira bien ..). Garder toutes ces bacs et tous les headers tiers hors de votre référentiel sont les meilleurs (bien que je ne puisse pas vous dire combien d'endroits où j'ai rencontré exactement le contraire). En outre, vous pouvez utiliser des variables d'environnement pour spécifier l'emplacement racine de vos 3rd Party Libs, puis il suffit de réfléchir au paramètre ENV dans vos fichiers de marque / projet. Cela aide si Devs aime monter l'emplacement partagé différemment.


@CCOOK - une note de plus sur la tierce partie libs: si vous les organisez par projet, assurez-vous de mettre chaque version des libs dans son propre répertoire nommé par numéro de version - par exemple. "3rd_Party / Boost / 1.44.0 / ". Cela simplifie considérablement la mise à niveau vers les nouvelles versions de la bibliothèque au besoin que possible de conserver plusieurs versions pendant une période de transition. Une fois que vous êtes convaincu que vous avez pleinement mis à niveau tous les projets, vous pouvez supprimer les anciennes versions de la bibliothèque. Ce système a bien fonctionné pour moi - YMMV.


@Mike merci! J'utilise mercurial, mais je ferai comme vous le suggérez en incluant le numéro de version dans les tiers libs