Posté par ajeandet .
En réponse à la dépêche E.T. téléphone Meson.
Évalué à 4.
Dernière modification le 09 octobre 2018 à 19:50.
Meson importe lui même les modules du monde entier (dans sa façon de voir les choses). C'est pour ça que vous avez un module Qt, GNOME, RPM, ... à mon sens ce n'est pas au build système de s'intégrer avec tous les frameworks de la terre entière.
Sauf quand les projets ont des besoins particuliers. On ne peut pas demander à chaque application de redévelopper tout ce qui était déjà fait et le réinclure. Il faut un endroit centralisé pour cela. Meson montre que comme autotools avec ses macros, il est capable de gérer les spécificités des projets. Dans le cas de GNOME, ça va être de compiler des schémas, des fichiers de ressources, de la documentation, des fichiers d'introspection. Compiler et générer, c'est le job du build system, alors pourquoi pas le centraliser là bas ? C'est un atout pour les projets souhaitant migrer.
J'ajouterais ici que le problème si il y en a un, est du coté des frameworks qui font leurs choix, imposent leurs outils (qmake -> incontournable pour inspecter un kit Qt), la solution de CMake n'est pas nécessairement très différente. De plus, la philosophie de Meson est de factoriser au maximum ces cas particuliers pour éviter une des dérives avec CMake qui est que chaque projet ship plus de LOC CMake que de code C/C++... avec des tonnes de modules CMake pour faire des choses assez banales. C'est une des justifications aussi du choix de ne pas faire un langage "Turing complete", ça empêche la prolifération de modules custom.
Si je prends encore l'exemple du module Qt, le code source est vraiment petit voir ici. Même si il n'est pas complet il me permet de compiler des applications avec Qt sans problème sur mac,linux,windows et cross win-linux.
Si on regarde ici meson Vs Cmake j'ai quand même l'impression que ça respecte les promesses, c'est quand même bien plus lisible non?
[^] # Re: Je n'aime pas
Posté par ajeandet . En réponse à la dépêche E.T. téléphone Meson. Évalué à 4. Dernière modification le 09 octobre 2018 à 19:50.
J'ajouterais ici que le problème si il y en a un, est du coté des frameworks qui font leurs choix, imposent leurs outils (qmake -> incontournable pour inspecter un kit Qt), la solution de CMake n'est pas nécessairement très différente. De plus, la philosophie de Meson est de factoriser au maximum ces cas particuliers pour éviter une des dérives avec CMake qui est que chaque projet ship plus de LOC CMake que de code C/C++... avec des tonnes de modules CMake pour faire des choses assez banales. C'est une des justifications aussi du choix de ne pas faire un langage "Turing complete", ça empêche la prolifération de modules custom.
Si je prends encore l'exemple du module Qt, le code source est vraiment petit voir ici. Même si il n'est pas complet il me permet de compiler des applications avec Qt sans problème sur mac,linux,windows et cross win-linux.
Si on regarde ici meson Vs Cmake j'ai quand même l'impression que ça respecte les promesses, c'est quand même bien plus lisible non?