Je trouve surtout que le mainteneur principal a supprimé les fichiers CMakeLists.txt et meson.build en 2017.
Et celui-ci semble envoyer bouler les contributeurs proposant la compatibilité avec CMake, supprime le titre des Pull Request et on trouve même des commentaires supprimés.
Crée le meson.build et ajoute le à la wrapDB. Il restera extérieur au projet mais utilisable avec un simple fichier descriptif. Le build system, de même que le packaging, n'a pas besoin de s'intégrer aux forceps dans un logiciel. Le mainteneur définit des outils par défaut, idéalement pas trop nul ni trop inconnus, mais ne peut intégrer tous les systèmes de l'univers. Je comprends donc qu'il refuse des patchs.
Ensuite ton IDE ne gère pas Meson... Bin je te dirais: pourquoi chercher à gérer un build system avec un IDE qui va essayer de faire des trucs automatiques. Apprends à utiliser Meson et à éditer un meson.build, tu ne devrais pas avoir à choisir ton build system d'après ton IDE, ni choisir ton IDE d'après la compatibilité avec ton build system.
Pour finir, pour avoir travaillé avec Conan quelques mois, il permet de faire du packaging de manière assez simple, est assez extensible, a une bonne quantité de logiciels déjà prépackagés, gère Meson et CMake... Si tu veux plus de flexibilité que ce que t'offre la wrapdb de Meson, tu peux facilement ajouter ton fichier meson ou cmake pour patcher le paquet avant de le builder.
Oui c'est plus long que faire un pip install, mais le problème vient du fait que ce n'est pas packagé (ou mal, cf vcpkg), pas du fait que c'est compliqué à installer une fois packagé. Si tu fais le boulot une fois c'est facilement partageable et réutilisable, pour que d'autres n'aient pas à s'arracher les cheveux comme toi. Il suffit de proposer tes modifications upstream à Conan et à la wrapDB de Meson.
# Ce que j'aurais tenté
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
Crée le
meson.buildet ajoute le à la wrapDB. Il restera extérieur au projet mais utilisable avec un simple fichier descriptif. Le build system, de même que le packaging, n'a pas besoin de s'intégrer aux forceps dans un logiciel. Le mainteneur définit des outils par défaut, idéalement pas trop nul ni trop inconnus, mais ne peut intégrer tous les systèmes de l'univers. Je comprends donc qu'il refuse des patchs.Ensuite ton IDE ne gère pas Meson... Bin je te dirais: pourquoi chercher à gérer un build system avec un IDE qui va essayer de faire des trucs automatiques. Apprends à utiliser Meson et à éditer un
meson.build, tu ne devrais pas avoir à choisir ton build system d'après ton IDE, ni choisir ton IDE d'après la compatibilité avec ton build system.Pour finir, pour avoir travaillé avec Conan quelques mois, il permet de faire du packaging de manière assez simple, est assez extensible, a une bonne quantité de logiciels déjà prépackagés, gère Meson et CMake... Si tu veux plus de flexibilité que ce que t'offre la wrapdb de Meson, tu peux facilement ajouter ton fichier meson ou cmake pour patcher le paquet avant de le builder.
Oui c'est plus long que faire un
pip install, mais le problème vient du fait que ce n'est pas packagé (ou mal, cf vcpkg), pas du fait que c'est compliqué à installer une fois packagé. Si tu fais le boulot une fois c'est facilement partageable et réutilisable, pour que d'autres n'aient pas à s'arracher les cheveux comme toi. Il suffit de proposer tes modifications upstream à Conan et à la wrapDB de Meson.