Bref, point de vue utilisateur du logiciel (depuis les sources, donc utilisateur avancé quand même), pas besoin même de « système de build » puisque du point de vue de celui qui exécute ./configure, autotools n'est pas nécessaire.
En fait on s'en fout pas mal de son point de vu. Ce que vous voulais c'est un système de packaging de sources standard hors ça n'existe pas parce qu'il y a pleins de projets qui ont déjà un système différents. On parle de C et C++, mais si tu joue avec des programmes en python, en java, en go, en rust, en js,... tu aura des dizaines de builder et c'est normale. Le build est un outil du développeur. Lui il l'exécute plusieurs dizaines de fois par jours. La minute qu'il perd à cause de sont build peut facilement représenter des dizaines de minutes dans la journée, ralentir son intégration continue ça ralenti tous sont travaille, ne pas pouvoir lancer un build + les tests tout le temps ça nuit à la qualité de ce qu'il te fourni.
À coté de ça changer les habitudes de quelques utilisateurs qui ne veulent pas lire un fichier INSTALL et qui ne veulent pas changer leur 3 commandes (alors qu'ils vont bien devoir installe meson, python et ninja !). Ça ne représente pas un intérêt énorme.
Les packageurs de distribution sont déjà habitués à gérer un paquet de builder différents (tu as même Debian (et d'autres je présume) qui fait des builds via différent compilateurs).
Le builder est un outil du développeurs, pas un système de packaging.
[^] # Re: Un nouveau standard ?
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
En fait on s'en fout pas mal de son point de vu. Ce que vous voulais c'est un système de packaging de sources standard hors ça n'existe pas parce qu'il y a pleins de projets qui ont déjà un système différents. On parle de C et C++, mais si tu joue avec des programmes en python, en java, en go, en rust, en js,... tu aura des dizaines de builder et c'est normale. Le build est un outil du développeur. Lui il l'exécute plusieurs dizaines de fois par jours. La minute qu'il perd à cause de sont build peut facilement représenter des dizaines de minutes dans la journée, ralentir son intégration continue ça ralenti tous sont travaille, ne pas pouvoir lancer un build + les tests tout le temps ça nuit à la qualité de ce qu'il te fourni.
À coté de ça changer les habitudes de quelques utilisateurs qui ne veulent pas lire un fichier INSTALL et qui ne veulent pas changer leur 3 commandes (alors qu'ils vont bien devoir installe meson, python et ninja !). Ça ne représente pas un intérêt énorme.
Les packageurs de distribution sont déjà habitués à gérer un paquet de builder différents (tu as même Debian (et d'autres je présume) qui fait des builds via différent compilateurs).
Le builder est un outil du développeurs, pas un système de packaging.