Posté par freem .
En réponse à la dépêche E.T. téléphone Meson.
Évalué à 7.
Dernière modification le 08 octobre 2018 à 15:14.
Perso, quand j'essaies d'utiliser CMake (et j'y arrive, tant bien que mal, l'air de rien), je crois que les 2 trucs qui me cassent le plus les pieds c'est:
l'intégration du (D)VCS. Il y a quantité de littérature sur comment extraire le dernier tag+le dernier hash court et l'intégrer dans le CMake, mais jusqu'ici, je n'ai rien trouvé de vraiment clair. En l'occurrence, je parle de git, le plus utilisé du moment selon mon pifomètre, mais je ne doute pas que le problème se retrouve avec les autres. Si je dois migrer à un nouveau BS (Build System, pas Bull Shit... quoique...) il va au moins falloir que ça, ce soit simple.
le triste "la compilation (ou est-ce le linkage? Je sais jamais) à échoué, vous pouvez avoir plus d'informations en passant -v". Sous-entendu: passer -v au compilo, pas à make, bien sûr. Bref, comment que ça se passe avec Meson?
Autre point qui m'a fait tiquer dans la dépêche:
Et au lieu d'imprimer les sorties les unes au-dessous des autres, la sortie précédente est effacée, permettant d'éviter les scrolls trop longs et de se concentrer sur le dernier élément. En outre, le compteur d'étape est agréable pour savoir où on en est dans la compilation (particulièrement pour les très gros projets aux longues compilations).
Euh, vous êtes sérieux la? Non, parce que si j'oublie un ";" après la "}" d'une classe ou structure en C++, l'erreur ne sera pas immédiate, mais arrivera bien après. Donc, c'est la 1ère erreur qui est importante, pas la dernière.
Ce n'est qu'un seul exemple, mais bien souvent dans mon cas les erreurs de compilations se corrigent en cascade, et pas comme un saumon qui remonte sa rivière...
Pour le reste, c'est à voir, si en effet il gère aisément les dépendances externes, ça peut être sympa, parce qu'avec CMake, quand on inclue une dépendance, on sait jamais si c'est LIBRARY, LIBRARIES, le nom n'est jamais trop sûr non plus et aller lire les fichiers qui l'indiquent (qui sont multiples) est bien lourd.
Sauf que, en fait, à bien y réfléchir, ça se fait pas trop mal avec cmake, si on utilise pkg-config, et non leur système intégré (parce que de toute façon, je me suis aperçu avec le temps que je finis toujours par utiliser des libs qui n'exposent pas de fichier cmake au système, alors que les fichiers pour pkg-config c'est la norme sous *nux).
Bon, je reconnaît que l'inconvénient du coup, c'est Windows. Pas comme si Windows n'avait jamais été une plaie dans la gestion des dépendances de build, non plus.
Conclusion pour ce paragraphe: et chez vous, pour exporter une lib, ça marche comment?
Pour ce qui est de ninja, j'ai lu dans le manuel de cmake une rumeur comme quoi il serait aussi supporté. Du coup, vu que la vitesse de meson semble l'argument de «vente» le plus mis en avant, et qu'il est avoué que c'est dû au fait d'utiliser uniquement ninja, ça donne quoi, une comparaison de vitesse à la loyale?
Parce qu'à moi, le fait de supporter un maximum de backend me semble une force, pas une faiblesse. J'avais lu il y a quelques années (dans le contexte de pondre une API de plugins) un papier des gens de chez google qui argumentaient sur le fait que, pour avoir une API à peu près stable et robuste, il fallait au moins 3 outils qui l'implémentent, et que plus il y en a, mieux c'est. Je n'arrive pas à le retrouver, mais ma mémoire m'indique que l'argumentaire était plutôt robuste et convainquant.
# Quelques questions...
Posté par freem . En réponse à la dépêche E.T. téléphone Meson. Évalué à 7. Dernière modification le 08 octobre 2018 à 15:14.
Perso, quand j'essaies d'utiliser CMake (et j'y arrive, tant bien que mal, l'air de rien), je crois que les 2 trucs qui me cassent le plus les pieds c'est:
Autre point qui m'a fait tiquer dans la dépêche:
Euh, vous êtes sérieux la? Non, parce que si j'oublie un ";" après la "}" d'une classe ou structure en C++, l'erreur ne sera pas immédiate, mais arrivera bien après. Donc, c'est la 1ère erreur qui est importante, pas la dernière.
Ce n'est qu'un seul exemple, mais bien souvent dans mon cas les erreurs de compilations se corrigent en cascade, et pas comme un saumon qui remonte sa rivière...
Pour le reste, c'est à voir, si en effet il gère aisément les dépendances externes, ça peut être sympa, parce qu'avec CMake, quand on inclue une dépendance, on sait jamais si c'est LIBRARY, LIBRARIES, le nom n'est jamais trop sûr non plus et aller lire les fichiers qui l'indiquent (qui sont multiples) est bien lourd.
Sauf que, en fait, à bien y réfléchir, ça se fait pas trop mal avec cmake, si on utilise pkg-config, et non leur système intégré (parce que de toute façon, je me suis aperçu avec le temps que je finis toujours par utiliser des libs qui n'exposent pas de fichier cmake au système, alors que les fichiers pour pkg-config c'est la norme sous *nux).
Bon, je reconnaît que l'inconvénient du coup, c'est Windows. Pas comme si Windows n'avait jamais été une plaie dans la gestion des dépendances de build, non plus.
Conclusion pour ce paragraphe: et chez vous, pour exporter une lib, ça marche comment?
Pour ce qui est de ninja, j'ai lu dans le manuel de cmake une rumeur comme quoi il serait aussi supporté. Du coup, vu que la vitesse de meson semble l'argument de «vente» le plus mis en avant, et qu'il est avoué que c'est dû au fait d'utiliser uniquement ninja, ça donne quoi, une comparaison de vitesse à la loyale?
Parce qu'à moi, le fait de supporter un maximum de backend me semble une force, pas une faiblesse. J'avais lu il y a quelques années (dans le contexte de pondre une API de plugins) un papier des gens de chez google qui argumentaient sur le fait que, pour avoir une API à peu près stable et robuste, il fallait au moins 3 outils qui l'implémentent, et que plus il y en a, mieux c'est. Je n'arrive pas à le retrouver, mais ma mémoire m'indique que l'argumentaire était plutôt robuste et convainquant.