Discussion :

[Bktero]

Bonjour,

Je viens de passer 2 semaines à prendre en main cmake. Après pas mal d'efforts, je suis capable de générer deux makefiles : un pour mon simulateur, un pour mon exécutable pour MCU. Tout est scriptable et c'est impeccable pour atteindre mon objectif d'automatiser les builds avec Jenkins. C'est cool.

Je réfléchis maintenant à comment cela va être utiliser au jour le jour par les développeurs et je viens de me prendre un mur : c'est le bazar pour ajouter un nouveau fichier cpp au projet. C'est pas cool du tout.

Comme je l'ai expliqué dans une discussion précédente, je génère des sources à partir de ressources lors de l'appel à cmake. Enfin, j'utilise des file(GLOB[_RECURSE] ...) pour lister mes fichiers sources (celles générées et les autres). Comme je fais du globbing pour récupérer mes fichiers sources, je suis obligé de ré-exécuter cmake à chaque fois que je créé un nouveau fichier cpp. Comme je ré-éxecute cmake, je re-génère mes sources à partir des ressources. Comme ces sources contiennent des hpp inclus dans d'autres fichiers, je me retrouve à recompiler énormément de fichiers à chaque fois je créé un nouveau fichier cpp, en plus de devoir rappeler cmake à la main.

J'ai lu plusieurs discussions stackoverflow disant qu'il ne faudrait pas faire de globbing et lister manuellement les sources. Ainsi, quand on créé un fichier cpp, on doit donc le rajouter dans le CMakeLists.txt. Au-delà des emmerdes pour lister manuellement mes fichiers actuels, je trouve ça bien relou de devoir éditer CMakeLists.txt à chaque que je vais créer un fichier cpp ou hpp. Cela va ré-évaluer le build system, je pense qu'en plus ça va re-générer mes sources et donc je tombe dans le même problème qu'au-dessus... Enfin, quand le projet fera des centaines de fichiers, j'imagine même pas le gueule du fichier CMakeLists.txt

D'un seul coup, je suis bien moins convaincu par cmake...

Comment listez-vous vos sources ?

Merci d'avance pour vos retours d'expérience

[jblecanard]

Salut

Tu touches un problème pour lequel il n'existe pas de solutions "canonique". Changer le chaîne de build n'y changera pas grand chose, aucune n'offre réellement de services de ce type. Le gros souci du GLOB de cmake est qu'il nécessite effectivement de devoir ré-exécuter l'initialisation du build. Donc je serais aussi d'avis de ne pas utiliser GLOB non plus. Mais comment faire alors pour que ça reste pratique ? Quelques pistes tirées de mon expérience perso.

Première chose : générer les fichiers out of source pour garantir que le code généré soit séparé du code écrit manuellement. Cela a de multiples avantages : pas de risque de pollution du système de versioning avec des fichiers générés, "clean" beaucoup plus facile à écrire (il suffit de supprimer le répertoire de build), maîtrise du contexte de compilation sur le code généré et du code écrit.

Deuxième chose : Ne pas utiliser GLOB pour le code écrit manuellement. Devoir modifier le CMakeLists.txt pour ajouter une unité de compilation n'est pas gênant, au contraire, je trouve que c'est une très bonne pratique. Ajouter une unité de compilation n'est pas anodin et son contexte de compilation doit être maîtrisé. A ce titre, ça ne fait pas de mal si le développeur fait l'effort d'ajouter une ligne. Mais surtout, ça a un avantage majeur sur le GLOB : si le code est bien séparé du code généré, il n'y a pas besoin d'exécuter CMake en entier pour prendre en compte le changement. Un simple rebuild_cache fonctionnera, sans avoir à appeler toute la partie génératrice. Et il se lance même tout seul si tu essayes de compiler une target existante. Seul l'ajout de target nécessite un rebuild_cache explicite.

Troisième chose : Si tu redoutes les listings de fichiers trop longs, alors casse ton CMaleLists.txt en plusieurs avec des include ou des add_subdirectory. De ce que je comprend de ton projet, il est assez gros avec potentiellement du monde dessus. Cela signifie qu'il va falloir imposer une discipline et un certain nombre de conventions. La structure à adopter dans les CMakeLists de listing en fait partie.

[ternel]

Les concepteurs de CMake eux-même recommandent de ne pas utiliser glob. Et pour cette raison précise.
En fait, glob est un bon outil pour un programme terminé.

Ce n'est pas du tout adapté pour un programme en cours de développement.

[Bktero]

Salut !

J'avais lu vos réponses en fin de semaine dernière mais je n'avais pas eu le temps de répondre ^^

Le gros souci du GLOB de cmake est qu'il nécessite effectivement de devoir ré-exécuter l'initialisation du build. Donc je serais aussi d'avis de ne pas utiliser GLOB non plus.
[...]
Devoir modifier le CMakeLists.txt pour ajouter une unité de compilation n'est pas gênant, au contraire, je trouve que c'est une très bonne pratique.

Les concepteurs de CMake eux-même recommandent de ne pas utiliser glob. Et pour cette raison précise.

J'ai bien vu que GLOB était déconseillé justement pour ces raisons. En tant que tel, je ne suis pas fan de devoir rajouter manuellement ton fichier. J'ai bossé ces dernières années avec Java/Eclipse et j'ai justement apprécié cette simplicité : tu crées une classe, ça te crée le fichier au bon endroit (limite tu ne sais pas où) et il est automatiquement utilisé. En parallèle de ces développements Java, j'ai fait des développements C avec plusieurs IDE : IAR Embedded Workbench, Keil µVision et Eclipse CDT. Et j'ai retrouvé dans Eclipse CTD la simplicité du Java : tu crées ton fichier au bon endroit dans ta hiérarchie de dossiers et le builder du CDT l'ajoute automatiquement au build. Quand le projet devient stable, je trouverai ça peut déranger de lister manuellement les fichiers : on en ajoute peu souvent. En revanche, en début de projet, tu en ajoutes souvent... Et comme je souhaite présenter le process de build le plus simple possible à mes collègues, ça ne va pas le faire.

Soit dit en passant, j'ai regardé plusieurs projets a priori de qualité sur Github et plusieurs utilisent GLOB, y compris des petits projets comme https://github.com/electronicarts/EASTL. Donc c'est pas la meilleure solution mais tu n'es pas un vaut-rien que tout le monde va montrer si tu le fais

En revanche, j'avais découvert la target rebuild_cache avant de lire vos réponses et elle semble être la solution à mon problème :

rebuild_cache (make rebuild_cache) re-runs cmake to regenerate the build system.

rebuild_cache – This target runs cmake on the source tree and picks up additional cache entries if they exist.

J'ai testé et cela ré-évaluer bien les GLOB. J'ai donc modifié mon fichier CMakeLists.txt pour ne générer les fichiers sources que s'ils n'existent pas. Quand j'ajoute un fichier, j'exécute la cible rebuild_cache et le nouveau fichier est pris en compte. Enfin, j'ai rajouté une cible force_generate_resources au nom explicite, qui me sert quand j'ajoute de nouvelles ressources (j'avais déjà une cible pour re-générer le code si les ressources existantes avaient changées).

Au final, c'est pas totalement parfait mais c'est satisfaisant