Pour moi tu as besoin que chaque brique ai une vocation spécifique de la quelle elle ne peut pas sortir. Ça réduit considérablement ton scope et rend l'analyse bien plus simple.
Le souci, c'est que compiler un logiciel, c'est fondamentalement de l’exécution d'un script qui lance des commandes. Tu devoir lancer des commandes arbitraires pour divers étapes, donc il y a toujours un risque que ça soit un peu open bar.
Avoir un fonctionnement déclaratif est parfait pour ça. Je suis intimement convaincu que l'énorme majorité des projets pourraient utiliser un paradigme déclaratif pour leur build, mais soit n'ont pas le bon état d'esprit soit ont une forme d'ego pensent que leur projet a une spécificité.
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.
Et encore une fois, il faut voir comment il y a eu une levée de bouclier quand on est passé d'un mode script (sysVinit) à un mode déclaratif (systemd) pour l'init, avec des gens défendant l'écriture de shell scripts. Je suis assez pro-systemd et pro-déclaratif, mais je ne pense pas que la dite levée de bouclier était une question d'ego ou d'état d'esprit. 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.
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).
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 4.
Le souci, c'est que compiler un logiciel, c'est fondamentalement de l’exécution d'un script qui lance des commandes. Tu devoir lancer des commandes arbitraires pour divers étapes, donc il y a toujours un risque que ça soit un peu open bar.
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.
Et encore une fois, il faut voir comment il y a eu une levée de bouclier quand on est passé d'un mode script (sysVinit) à un mode déclaratif (systemd) pour l'init, avec des gens défendant l'écriture de shell scripts. Je suis assez pro-systemd et pro-déclaratif, mais je ne pense pas que la dite levée de bouclier était une question d'ego ou d'état d'esprit. 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.
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).