Système de compilation C ++ portable

Je recherche un bon système de construction portable pour les projets C ++, facile à entretenir. Les plates-formes principales doivent inclure Windows (Visual Studio 8+) et Linux (gcc); Cygwin peut être un avantage. Nous envisageons deux possibilités principales: CMake et Boost.Jam . Les SCons peuvent aussi être une option, mais je n’ai pas encore étudié la question. CMake et Boost.Jam semblent avoir les traits suivants:

CMake:

  • (+) génère un “makefile” natif (solution pour Windows, projet pour Eclipse)
  • (+) extensions pour tests et packaging
  • (-) demande un fichier de configuration dans chaque dossier de projet
  • (-) basé sur un langage particulier un peu trop verbeux

Boost.Jam:

  • construit par lui-même sans étapes intermédiaires
  • (-) ne génère pas de solutions / projets natifs
  • (+) langage concis semblable au makefile classique
  • (+) prise en charge intuitive de propriétés comme le multithreading et la bibliothèque statique / dynamic

Quelles sont les autres possibilités et qu’est-ce qui est vraiment préférable après l’expérience? Quels systèmes de construction peuvent créer une solution sur le chemin?

(-) demande un fichier de configuration dans chaque dossier de projet

Ce n’est pas correct, il vous suffit de passer par de plus grands chemins comme:

add_program(foo src/foo.cpp src/main.cpp) 

Quelques notes à propos de Boost.Jam – d’abord, il ne s’agit pas de Boost.Jam – bjam à lui tout seul, mais ce que vous recherchez, c’est Boost.Build, qui est composé de macros de confiture qui rendent bjam utile.

Maintenant, j’ai travaillé avec les deux, et je dois admettre que Boost.Build ne convient à aucun projet sérieux en dehors du Boost lui-même. Besoin de trouver une bibliothèque? Vous ne pouvez pas avoir besoin de trouver un en-tête? Ne peut pas. Besoin de faire quelque chose en dehors de la construction simple – et vous n’avez aucune idée de la façon de le faire en tant que documentation BB … Totalement inutile et peut-être couvrir 10% de BB. Donc, dans la plupart des cas, vous devez poser des questions dans les listes de diffusion BB et …

Donc, si vous avez un projet compliqué – et que vous avez besoin de créer quelque chose de plus que simplement comstackr et lier, restz à l’écart de Boost.Build.

Donc, si vous avez besoin de soutenir MSVC, je trouve aujourd’hui que CMake n’est que le choix possible.

Je ne dis pas que CMake est un très bon système, il a de nombreux problèmes, mais il convient surtout au développement multi-plateformes (si vous devez prendre en charge MSVC).

Et si vous ne vous souciez pas de MSVC et que vous êtes satisfait de MinGW … jetez également un coup d’œil à autotools.

À propos de Scons – il est encore moins mûr que leur CMake.

C’est un peu un coup de gueule, mais je vais essayer de restr objective et de ne rapporter que mes expériences:

J’ai essayé plusieurs fois CMake et je suis sur le point d’arriver à un point où je me porterai volontaire pour gérer des fichiers de projet distincts pour chaque environnement de compilation ou pour utiliser le système de compilation d’une autre langue (Ant, NAnt, MSBuild ou autre) afin de comstackr et d’empaqueter mes fichiers. Projets C ++.

CMake, tel qu’il est:

  • Il remplace un format laid, mais formalisé (Makefile) par un format libre incroyablement mal conçu (CMakeLists.txt)
  • Il supprime sa configuration, son cache et d’autres éléments encombrants dans tous les répertoires sans aucun respect pour les tentatives de l’utilisateur de maintenir l’architecture source propre.
  • La documentation de CMake fait défaut dans la plupart des endroits (par exemple, essayez d’append de manière récursive un répertoire source à une cible sans exclure certains fichiers pour commencer).
  • Les projets IDE générés sont incroyablement pauvres (vous avez un projet Visual Studio bien structuré? CMake dumpera toutes vos sources dans un seul nœud de projet)
  • Les projets IDE générés utilisent des chemins absolus (vous ne pouvez donc pas les enregistrer dans le contrôle de source – tout le monde doit utiliser CMake)
  • Vous pouvez uniquement choisir entre les plates-formes (par exemple, x64 et x86) lors de la génération de projets / makefiles. CMake ne générera pas de projets prenant en charge plusieurs plates-formes, même si cela convient parfaitement à l’IDE.
  • Très peu de contrôle sur la façon dont les bibliothèques sont référencées. Il existe un éventail de méthodes de recherche de référence (donc, même avec un contrôle faible, vous ne pouvez vous attendre à aucune uniformité).

Mon sharepoint vue personnel est que même si l’on voulait concevoir intentionnellement le pire système de construction multi-plateforme possible, il serait difficile de faire pire que CMake.

Je n’ai aucune expérience avec Boost.Build et il pourrait avoir des lacunes tout aussi importantes, mais le mieux que je puisse dire à propos de CMake est que, si vous ne voulez que créer des fichiers source, cela peut vous permettre de faire le travail – – bien que cela soit très pénible pour les développeurs et les utilisateurs de bibliothèques / applications.

J’ai eu de bonnes expériences avec premake4: http://indussortingousone.com/premake

Mettre à jour

J’aime toujours Premake, mais après avoir travaillé avec cela pendant un certain temps, je me sens obligé d’énumérer certaines des lacunes que j’ai trouvées:

  • L’intégration de nouvelles chaînes d’outils (outils de prétraitement tels que bison ou moc) n’est pas prise en charge.
  • Pas de support pour la configuration par fichier.
  • La recherche de bibliothèque est inflexible, pas de support pour le script ou la vérification de version.
  • Certaines directives (par exemple, la configuration) affectent les instructions suivantes, mais il n’y a pas de délimitation explicite de la scope. Cela peut conduire à des erreurs subtiles.
  • Autrement dit, peu d’aide pour le débogage de la configuration, montrant comment la configuration est interprétée, autre que l’examen des scripts de génération générés ou leur exécution.
  • Pour gmake Makefiles au moins, il n’ya pas d’option permettant de rendre les chemins absolus. Cela ne fonctionne pas bien avec le correctif rapide de Vim, bien qu’il soit facile de contourner le problème.
  • Rythme de développement lent. De nouvelles fonctionnalités peuvent être en développement pendant des années .

Je suivrai @Akusete sur QMake , qui est mon outil personnel de choix pour le moment. Les avantages et les inconvénients sont aussi un peu personnels, mais les voici:

Avantages:

  • Langage de script beaucoup plus concis, comparé à CMake;
  • Peut générer des projets VS et des makefiles compatibles jom sous Windows;
  • Ajouter des chaînes d’outils pour, par exemple, une compilation croisée est très facile (cela revient à un mkspec personnalisé, écrit dans le même langage qmake );

Les inconvénients:

  • Une liberté un peu limitée pour créer un nombre arbitraire de cibles. Certaines sont prédéfinies, telles que app , lib etc., mais il est un peu fastidieux de créer, par exemple, des versions de bibliothèques partagées et statiques en une seule passe, ou de désactiver l’en-tête précompilé pour un seul fichier source. C’est tout à fait réalisable, mais nécessite un peu de google et a l’air sale;
  • Liée à Qt par défaut (qui est facilement remplacée par l’ajout de QT -= core gui ligne QT -= core gui )

Global:

Fait le travail rapidement sur des projets simples à moyens, mais laisse toujours le sentiment de “putain, cela aurait pu être fait d’une manière plus simple!” lorsqu’il est appliqué à des tâches complexes.