Ah cool un journal de serge_sans_paille, je vais apprendre des trucs.
Merci pour ce super journal qui me fait découvrir un nouvel outil :) Mais tu oublies de nous parler d'un autre moyen d'éviter le conflit de noms à l'édition des liens : utiliser le mot clé static. Et oui, ainsi la fonction aura la visibilité hidden dans chaque unité de compilation qui inclut l'entête et pour peu qu'il n'y ait pas de problème de gardes d'inclusions ça devrait passer.
Bon évidemment il ne faut pas faire cela. Déjà parce que sémantiquement c'est tordu, et aussi parce qu'on passe pour un débutant qui débarque d'un de ces langages ésotériques où la déclaration et la définition sont dans le même fichier. Mais surtout, il faut éviter d'implémenter les fonctions dans les entêtes parce que ça crée du couplage entre l'implémentation de la fonction et le code qui inclut l'entête ; et y'en a ras la casquette de recompiler la terre entière dès qu'on touche à un entête, non mais, hein !
À part ça je regardais le style-check.yml de xsimd et puisque j'en suis à donner mon avis alors que personne ne le demande, je vais vous dire deux choses les enfants : Premièrement, n'écoutez pas les inconnus qui affirment des trucs sur Internet. Deuxièmement : les étapes de votre CI doivent être lançables par les devs sur leurs machines. Ici on a un bon exemple puisque l'étape qui vérifie l'oubli d'inline dans les entêtes consiste à lancer un script bash dispo dans le dépôt. Je suis plus mitigé pour le clang-format qui lance une action GitHub tirée d'un autre dépôt ; impossible de lancer ça simplement en local. Quant à cross.yml et ses commandes shell qui s'étalent sur 40 lignes... bien malheureux celui qui aura à reproduire le build sur sa machine. À mon humble avis, ces 40 lignes devraient plutôt ressembler à sh ./test/cross-compile.sh --compiler ${matrix.sys.compiler} --compiler-version {matrix.sys.version} ...
Pourquoi faut-il sortir les scripts des fichiers de config de la CI vous demandez-vous?
Déjà comme on vient de le voir, pour que les développeurs puissent lancer les tâches sur leur machines de développement. Pourquoi attendre d'avoir poussé sa branche, lancé la CI, construit 50 images Docker, exécuté 30 étapes de configs, pour au final apprendre que le fichier foo.cpp n'est pas bien formaté ; alors qu'on peut avoir l'info lors du commit en configurant une hook Git qui lance exactement le même script que la CI ? C'est une perte de temps pour les devs.
D'autre part, vous souvenez-vous de Jenkins ? De Travis-CI ? Des autres outils de CI qui promettaient une config déclarative hyper simple ? Peu importe :) La CI ça va ça vient, et c'est bien dommage de lier ses tests avec une CI donnée. Que va-t-il se passer quand Elon Musk achètera GitHub et que tout le monde partira sur GitLab ? Il faudra encore réécrire tous ces fichiers de config. Adieu l'action clang-format, adieu cross.yml, il faut trouver autre chose. Mais on peut faire mieux ! Si tous ces tests étaient dans des scripts, ça marcherait partout ; et la config de la CI ne serait qu'une légère couche pour faire la glu entre les deux.
Bon j'ai l'air d'un vieux râleur mais franchement merci pour ce journal, je suis impatient de lire les suivants :)
# Chouette journal
Posté par Julien Jorge (site web personnel) . En réponse au journal Les codes fantastiques (et où les trouver). Évalué à 10. Dernière modification le 02 juillet 2023 à 16:49.
Ah cool un journal de serge_sans_paille, je vais apprendre des trucs.
Merci pour ce super journal qui me fait découvrir un nouvel outil :) Mais tu oublies de nous parler d'un autre moyen d'éviter le conflit de noms à l'édition des liens : utiliser le mot clé
static. Et oui, ainsi la fonction aura la visibilité hidden dans chaque unité de compilation qui inclut l'entête et pour peu qu'il n'y ait pas de problème de gardes d'inclusions ça devrait passer.Bon évidemment il ne faut pas faire cela. Déjà parce que sémantiquement c'est tordu, et aussi parce qu'on passe pour un débutant qui débarque d'un de ces langages ésotériques où la déclaration et la définition sont dans le même fichier. Mais surtout, il faut éviter d'implémenter les fonctions dans les entêtes parce que ça crée du couplage entre l'implémentation de la fonction et le code qui inclut l'entête ; et y'en a ras la casquette de recompiler la terre entière dès qu'on touche à un entête, non mais, hein !
À part ça je regardais le style-check.yml de xsimd et puisque j'en suis à donner mon avis alors que personne ne le demande, je vais vous dire deux choses les enfants : Premièrement, n'écoutez pas les inconnus qui affirment des trucs sur Internet. Deuxièmement : les étapes de votre CI doivent être lançables par les devs sur leurs machines. Ici on a un bon exemple puisque l'étape qui vérifie l'oubli d'inline dans les entêtes consiste à lancer un script bash dispo dans le dépôt. Je suis plus mitigé pour le clang-format qui lance une action GitHub tirée d'un autre dépôt ; impossible de lancer ça simplement en local. Quant à cross.yml et ses commandes shell qui s'étalent sur 40 lignes... bien malheureux celui qui aura à reproduire le build sur sa machine. À mon humble avis, ces 40 lignes devraient plutôt ressembler à
sh ./test/cross-compile.sh --compiler ${matrix.sys.compiler} --compiler-version {matrix.sys.version} ...Pourquoi faut-il sortir les scripts des fichiers de config de la CI vous demandez-vous?
Déjà comme on vient de le voir, pour que les développeurs puissent lancer les tâches sur leur machines de développement. Pourquoi attendre d'avoir poussé sa branche, lancé la CI, construit 50 images Docker, exécuté 30 étapes de configs, pour au final apprendre que le fichier foo.cpp n'est pas bien formaté ; alors qu'on peut avoir l'info lors du commit en configurant une hook Git qui lance exactement le même script que la CI ? C'est une perte de temps pour les devs.
D'autre part, vous souvenez-vous de Jenkins ? De Travis-CI ? Des autres outils de CI qui promettaient une config déclarative hyper simple ? Peu importe :) La CI ça va ça vient, et c'est bien dommage de lier ses tests avec une CI donnée. Que va-t-il se passer quand Elon Musk achètera GitHub et que tout le monde partira sur GitLab ? Il faudra encore réécrire tous ces fichiers de config. Adieu l'action clang-format, adieu cross.yml, il faut trouver autre chose. Mais on peut faire mieux ! Si tous ces tests étaient dans des scripts, ça marcherait partout ; et la config de la CI ne serait qu'une légère couche pour faire la glu entre les deux.
Bon j'ai l'air d'un vieux râleur mais franchement merci pour ce journal, je suis impatient de lire les suivants :)