Dans mes souvenir un pauvre hello world en C++ se retrouve tout de suite avec des tonnes d'includes en cascade, dont beaucoup ne sont des bibliothèques standards fournies par le compilo (donc ne devant jamais changer en théorie...).
Ce qui est bien avec "en théorie" c'est que cela ne marche jamais ;)
Pour faire un vrai build reproductible à 100%, tu ne peux pas supposer que tes dépendances système ne changent pas. Et aussi, tu ne veux pas utiliser les dépendances système, car tu n'as pas de contrôle dessus, mais ceci est une autre histoire. En bref, tu veux absolument faire ce traitement de vérification.
Je serais intéressé par des benchmarks, mais le coût de l'appel système pour construire la liste de dépendance est très faible comparé au coût du build. Et une fois que le build est fait, tu as un cache du graph de dépendance, la seule chose qui devient nécessaire c'est de vérifier que tes dépendances sont à jour.
L'approche est intéressante et déja utilisée dans de nombreux autre outils:
Le problème de cette approche c'est que tu ne connais le graph de dépendance qu'une fois que tu a réalisé un build complet, ce qui est acceptable sur un petit projet, mais pas sur un gros, car en pratique on build rarement un projet en entier. Par example, ici, je travaille sur une sous partie d'un projet logiciel dont le build ne prend que 2h sur mon gros i7. Mais l'ensemble du projet prend plusieurs jours.
Note que ce n'est pas une critique fondamentale de l'outil, c'est un problème seulement si tu as un gros projet pour lequel tu veux faire un build partiel.
[^] # Re: Quid des perfs ?
Posté par Guillaum (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 6.
Ce qui est bien avec "en théorie" c'est que cela ne marche jamais ;)
Pour faire un vrai build reproductible à 100%, tu ne peux pas supposer que tes dépendances système ne changent pas. Et aussi, tu ne veux pas utiliser les dépendances système, car tu n'as pas de contrôle dessus, mais ceci est une autre histoire. En bref, tu veux absolument faire ce traitement de vérification.
Je serais intéressé par des benchmarks, mais le coût de l'appel système pour construire la liste de dépendance est très faible comparé au coût du build. Et une fois que le build est fait, tu as un cache du graph de dépendance, la seule chose qui devient nécessaire c'est de vérifier que tes dépendances sont à jour.
L'approche est intéressante et déja utilisée dans de nombreux autre outils:
Le problème de cette approche c'est que tu ne connais le graph de dépendance qu'une fois que tu a réalisé un build complet, ce qui est acceptable sur un petit projet, mais pas sur un gros, car en pratique on build rarement un projet en entier. Par example, ici, je travaille sur une sous partie d'un projet logiciel dont le build ne prend que 2h sur mon gros i7. Mais l'ensemble du projet prend plusieurs jours.
Note que ce n'est pas une critique fondamentale de l'outil, c'est un problème seulement si tu as un gros projet pour lequel tu veux faire un build partiel.