Meson ce n'est pas que les performances (pour beaucoup dues à ninja):
- lisibilité du code
- disparition des problèmes de quoting de CMake
- activation des warnings par défaut (parce que les débutants ne savent pas qu'il faut les activer, et ne le font donc pas, alors que ce sont ceux qui en ont le plus besoin)
- obligation de fait du build out-of-tree, parce que les développeurs peuvent casser le out-of tree en ne testant que le in-tree
- unique backend ninja: le choix a été fait de ne pas utiliser make, mais ninja qui est plus restreint et plus spécialisé. ninja ne gère que les dépendances, quitte à faire des fichiers verbeux, mais qui ne contiennent pas de logique à évaluer (pas de scripts bash, etc.). En contrepartie, on utilise un générateur de fichier de build ninja, comme Meson ou CMake.
- génération de fichiers pour Xcode ou Visual Studio
- gestion de la cross compilation
- utilisation massive de pkg-config pour la gestion de dépendances
- gestion de sous projets, ce qui permet de télécharger et builder GTK+ et toutes ses dépendances en une passe.
- gestion des SCU ou « unity builds »
Ensuite ce n'est pas une solution magique. Il y a encore des soucis, et j'avais entendu que la gestion d'Android n'était pas son fort, donc ce n'est peut être pas adapté à ton besoin. Mais cela a été assez pour convaincre de nombreux projets de l'utiliser (en migration ou compltément de leur ancien build system):
- GStreamer
- Tracker
- GNOME
- Shotwell
- Mesa
[^] # Re: Analyse très subjective!
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 10. Dernière modification le 15 juin 2018 à 12:19.
Je te conseille aussi de lire les objectifs de Meson et ceux de ninja.
Meson ce n'est pas que les performances (pour beaucoup dues à ninja):
- lisibilité du code
- disparition des problèmes de quoting de CMake
- activation des warnings par défaut (parce que les débutants ne savent pas qu'il faut les activer, et ne le font donc pas, alors que ce sont ceux qui en ont le plus besoin)
- obligation de fait du build out-of-tree, parce que les développeurs peuvent casser le out-of tree en ne testant que le in-tree
- unique backend ninja: le choix a été fait de ne pas utiliser make, mais ninja qui est plus restreint et plus spécialisé. ninja ne gère que les dépendances, quitte à faire des fichiers verbeux, mais qui ne contiennent pas de logique à évaluer (pas de scripts bash, etc.). En contrepartie, on utilise un générateur de fichier de build ninja, comme Meson ou CMake.
- génération de fichiers pour Xcode ou Visual Studio
- gestion de la cross compilation
- utilisation massive de pkg-config pour la gestion de dépendances
- gestion de sous projets, ce qui permet de télécharger et builder GTK+ et toutes ses dépendances en une passe.
- gestion des SCU ou « unity builds »
Ensuite ce n'est pas une solution magique. Il y a encore des soucis, et j'avais entendu que la gestion d'Android n'était pas son fort, donc ce n'est peut être pas adapté à ton besoin. Mais cela a été assez pour convaincre de nombreux projets de l'utiliser (en migration ou compltément de leur ancien build system):
- GStreamer
- Tracker
- GNOME
- Shotwell
- Mesa
Mais aussi Xorg, libinput, et d'autres...