Tu devoir lancer des commandes arbitraires pour divers étapes[...]
Je ne le crois pas. La majorité des projets sont globalement la même chose, je ne crois pas qu'il soit nécessaire de lancer doom dans son système de build. Réinventer un build pour chaque bibliothèque est un échec d'ingénieure.
Je suis d'accord qu'on peut faire mieux, mais tu as le risque de multiplier les DSL si tu limites trop, ce qui est déjà aussi un probléme, on a un DSL pour le Makefile, un DSL pour générer le fichier configure, basé sur un autre DSL via M4, le tout qui produit un script avec des idiomes spécifique pour être portable.
Multiplier les DSL n'est pas fondamentalement problématique à mon humble avis. S'ils restent simples ça n'est pas un coût si important. Là M4 est capable de muter le système de build.
[...] je ne pense pas que la dite levée de bouclier était une question d'ego ou d'état d'esprit.
Je n'en ai pas la preuve, mais j'en suis convaincu. Une standardisation du build (comme on peut le voir avec maven qui décrit l'arborescence d'un projet, les étapes d'un build, etc) est souvent mal vu parce que ça fait 50 ans qu'il y a des dizaines/centaines de manières de faire qui perdurent de génération en génération. L'intérêt de cette standardisation n'est pas perçu par des développeurs qui ont l'habitude de faire leur petits tricks pour ajouter tel cache ou faire de la précompilation des en-têtes, alors que c'est vécu comme un affront de faire autrement (pour un choix qui n'est pas fondamentalement mieux qui est juste une règle).
C'est pareil pour les gestionnaires de paquets pour distro, sauf erreur de ma part, y en a aucun qui n'a de possibilité de faire des scripts.
C'est vrai, je ne sais pas à quel point c'est utilisé dans debian, la plupart des paquets ne devraient pas en avoir besoin du tout (dès maintenant) et pour les autres cartographier les cas (ajout de modules dans le noyau, ajout d'une police,...) pourrait réduire à peau de chagrin les cas où c'est utile.
Et un dernier souci, c'est à mon avis la difficulté à imposer une norme dans certaines écosystèmes comme le C. C'est en effet bien mieux dans Rust ou Go, mais même la, tu as des échappatoires comme le build.rs (et rien en Go, que je sache).
Tout à fait et "convention over configuration" ça n'a pas infusé partout malheureusement.
Après chacun fais bien ce qu'il veut, mais j'évite autant que possible de complexifier le build.
[^] # Re: Combo glibc/systemd
Posté par barmic 🦦 . En réponse au journal Xz (liblzma) compromis. Évalué à 2.
Je ne le crois pas. La majorité des projets sont globalement la même chose, je ne crois pas qu'il soit nécessaire de lancer doom dans son système de build. Réinventer un build pour chaque bibliothèque est un échec d'ingénieure.
Multiplier les DSL n'est pas fondamentalement problématique à mon humble avis. S'ils restent simples ça n'est pas un coût si important. Là M4 est capable de muter le système de build.
Je n'en ai pas la preuve, mais j'en suis convaincu. Une standardisation du build (comme on peut le voir avec maven qui décrit l'arborescence d'un projet, les étapes d'un build, etc) est souvent mal vu parce que ça fait 50 ans qu'il y a des dizaines/centaines de manières de faire qui perdurent de génération en génération. L'intérêt de cette standardisation n'est pas perçu par des développeurs qui ont l'habitude de faire leur petits tricks pour ajouter tel cache ou faire de la précompilation des en-têtes, alors que c'est vécu comme un affront de faire autrement (pour un choix qui n'est pas fondamentalement mieux qui est juste une règle).
C'est vrai, je ne sais pas à quel point c'est utilisé dans debian, la plupart des paquets ne devraient pas en avoir besoin du tout (dès maintenant) et pour les autres cartographier les cas (ajout de modules dans le noyau, ajout d'une police,...) pourrait réduire à peau de chagrin les cas où c'est utile.
Tout à fait et "convention over configuration" ça n'a pas infusé partout malheureusement.
Après chacun fais bien ce qu'il veut, mais j'évite autant que possible de complexifier le build.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll