Quand étudier les moteur de production type CMake ?

Si tu es en dehors de ces cas, tant mieux pour toi

C’est pas "tant mieux", c’est un choix a faire d’imposer ou non un compilateur, avec les conséquences qui vont avec (pour les utilisateurs, mais également pour ceux qui maintiennent le projet).

Et je n’ai pas l’impression d’utiliser des fonctionnalités obscures.

Bref, peu importe. Pour moi, imposer un compilateur est un choix technique comme un autre. Idem pour le système de build.

Ma question cherche plutôt à comprendre pourquoi ce serait le mal absolu que la configuration du projet utilise un compilateur particulier alors que ça passe crème d’imposer le système de build.

@entwanne, Parce que ce n’est pas la même difficulté, aussi. Permettre d’utiliser différents compilateurs est relativement facile (surtout avec un système de build moderne). Permettre d’utiliser différents système de build est une gageure. J’ai bossé sur des projets qui le permettaient, et je n’ai jamais vu que les deux systèmes produisent le même résultat. Je ne parle pas d’être identique au bit près, mais seulement d’avoir les mêmes options et dépendances par défaut, et possibles. Et deux systèmes de build, c’est littéralement doubler le travail de support des builds.

D’accord merci pour vos réponses et précisions.

Ça me fait lever une autre interrogation (n’ayant bossé que sur des projets C de taille relativement modeste) : on parle depuis le début d'imposer un compilateur quand celui-ci serait encodé en dur dans le système de build.
C’est si compliqué que ça généralement que de compiler le projet avec un autre outillage que celui qui a été prévu par le mainteneur ?

Je veux dire que ça demande forcément un petit travail d’adaptation et que ça peut être rédhibitoire, mais est-ce que c’est insurmontable si le projet ne dépend pas d’options « exotiques » ?

mais est-ce que c’est insurmontable si le projet ne dépendant pas d’options « exotiques » ?

J’ai l’impression que le principal point est ici pour l’aspect compilateur (système de build, j’ai pas expérimenté sur de multiples projets). Ça vaut ce que ça vaut, mais sur toutes les études de cas open-source qu’on a fait avec Frama-C par exemple, on est systématiquement tombé sur du code supporté par "compilateur truc" mais qui est en dehors du standard C et pas supporté de la même manière par tout le monde.

La syntaxe pour les commandes de GCC et MSVC sont juste pas pareil. Meme sans option exotique, c’est forcement du code différent. Une simple activation des warnings, c’est -Wall dans un cas et /W4 dans l’autre.

A moins que j’ai loupé un truc dans cmake, il n’existe d’option CMAKE_ACTIVE_ALL_WARNINGS qui appellerait la bonne syntaxe en fonction du compilateur.

Cela dépend du type de projet (ça me semblait évident, je ne l’ai pas précisée). Mais pour des gros clients a plusieurs millions, tu peux juste pas te permettre de dire "ça devrait marcher". Tu dois pouvoir dire "on a testé et ça marche".

Ça serait catastrophique, d’un point de vue commercial et d’image, qu’on dise a un client qu’il peut faire la migration de la version X a la version Y et qu’il réalise que cela ne fonctionne pas et doit revenir a la version X. Ou qu’on lui dise "ca devrait marcher avec tel compilateur" et que ca ne soit pas le cas.

Et pour pouvoir dire "on a testé et ça marche", cela peut vouloir dire en interne qu’il faut synchroniser les systèmes de build de plusieurs centaines de projets, plusieurs centaines de devs, des dizaines de systèmes de CI, et potentiellement passer des semaines de validation manuelles.

Dans ces conditions, dire "on a testé et ça marche" pour 2 compilateurs différents, ça peut être énormément de boulot. (Même sans options de compilation spécifiques a chaque compilateur). Et en fonction des clients visés, on peut choisir de supporter plusieurs compilateurs, mais aussi d’imposer un compilateur, voire une version particulière d’un compilateur. ("imposé" dans le sens ou on dit aux clients "si vous utilisez autre chose, on ne garantie rien… sauf si vous payez).

Les processus de validation d’un produit peuvent être ultra simple ou ultra lourd et compliqué. Ce qui implique des choix techniques différents. On peut pas dire qu’on impose jamais le compilateur, ça dépend trop du type de projet. (Et je ne parle même pas des domaines critiques, la validation peut être encore pire)

Je veux dire que ça demande forcément un petit travail d’adaptation et que ça peut être rédhibitoire, mais est-ce que c’est insurmontable si le projet ne dépend pas d’options « exotiques » ?

J’ai bossé avec AIX. Tu n’as pas envie de compiler des trucs avec xlc (le compilateur proprio de l’OS). Crois-moi. Pour un cas moins extrême, je plussoie gbdivers.

Ce n’est pas insurmontable, surtout si le projet est petit, mais devoir gérer à la main tous les OS et tous les compilateurs, ça devient vite la galère. Regarde ce que fait CMake pour gérer les différents compilateurs.