Pourquoi les builds incrémentiels dans "make" n'utilisent pas d'algorithmes de hachage?

10

Je suis un débutant makeet je me demande quand l'utiliser make clean.

Un collègue m'a dit que les versions incrémentielles makesont basées sur les horodatages des fichiers. Donc, si vous extrayez une ancienne version d'un fichier dans votre VCS, il aura un "ancien" horodatage et il sera marqué comme "pas besoin de recompiler ce fichier". Ensuite, ce fichier ne serait pas inclus dans la prochaine génération.
Selon ce même collègue, ce serait une raison de l'utiliser make clean.

Quoi qu'il en soit, j'ai à peu près obtenu la réponse à la question "quand l'utiliser make clean" à partir d'autres questions StackExchange, mais mon autre question est alors:

Pourquoi les builds incrémentiels utilisant makes'appuient-ils sur des horodatages de fichiers et non sur SHA-1 par exemple? Git, par exemple, montre que nous pouvons déterminer avec succès si un fichier a été modifié en utilisant le SHA-1.
Est-ce pour des problèmes de vitesse?

builds make filaton
la source
5
makea été créé dans les années 70. SHA-1 a été créé dans les années 90. Git a été créé dans les années 00. La dernière chose que vous voulez, c'est que certaines versions obscures qui fonctionnaient depuis 30 ans échouent soudainement parce que quelqu'un a décidé de passer à la modernité avec un système éprouvé.
Ordous
1
Hacher les fichiers tout le temps est lent. Je pense que git utilise également les métadonnées du système de fichiers pour optimiser ses vérifications des fichiers modifiés.
CodesInChaos
4
La solution originale basée sur les dates de fichiers est très simple, elle n'a pas besoin de fichiers supplémentaires pour stocker les codes de hachage et elle a remarquablement bien fonctionné sur plusieurs décennies. Pourquoi quelqu'un devrait-il remplacer une solution qui fonctionne bien par une solution plus compliquée? De plus, AFAIK la plupart des systèmes VCS attribuent aux fichiers extraits la "date de sortie", donc les fichiers modifiés provoqueront correctement une recompilation sans "nettoyer".
Doc Brown
@Ordous: Amusant, mais est-ce pertinent ici? Le logiciel ne rouille pas; il donne parce que quelqu'un a changé quelque chose dans l'environnement environnant. À moins qu'ils ne le fassent pas, auquel cas cela devrait toujours fonctionner.
Robert Harvey
1
@RobertHarvey Bien sûr que ça l'est! Bien sûr, si vous ne mettez pas à jour votre, makevotre logiciel ne se cassera pas, mais makefait plutôt un effort pour avoir une compatibilité descendante dans les nouvelles versions. Changer le comportement de base sans raison valable est à peu près le contraire. Et les dates montrent pourquoi il n'a pas été initialement conçu pour utiliser SHA-1, ou pourquoi il n'a pas été facile de le moderniser lorsqu'il est devenu disponible (il makeavait déjà des décennies à l'époque).
Ordous

Réponses:

7

Un problème évident (et sans doute superficiel) serait que le système de génération devrait garder une trace des hachages des fichiers qui ont été utilisés pour la dernière génération. Bien que ce problème puisse certainement être résolu, il nécessiterait un stockage latéral lorsque les informations d'horodatage sont déjà présentes dans le système de fichiers.

Plus sérieusement, cependant, le hachage ne véhiculerait pas la même sémantique. Si vous savez que le fichier T a été construit à partir de la dépendance D avec le hachage H 1 , puis découvrez que D est maintenant haché en H 2 , devriez-vous reconstruire T ? Probablement oui, mais il se pourrait aussi que H 2 fait référence à une ancienne version du fichier. Les horodatages définissent un ordre tandis que les hachages ne sont comparables que pour l'égalité.

Une fonctionnalité prise en charge par les horodatages est que vous pouvez simplement mettre à jour l'horodatage (par exemple, en utilisant l'utilitaire de ligne de commande POSIX touch) afin de vous faire makecroire qu'une dépendance a changé ou - plus intéressant - une cible est plus récente qu'elle ne l'est réellement. Tout en jouant avec cela est une excellente occasion de vous tirer une balle dans le pied, il est utile de temps en temps. Dans un système basé sur le hachage, vous auriez besoin du support du système de build lui-même pour mettre à jour sa base de données interne des hachages utilisés pour la dernière build sans réellement construire quoi que ce soit.

Bien qu'un argument puisse certainement être avancé pour utiliser des hachages sur des horodatages, mon point de vue est qu'ils ne sont pas une meilleure solution pour atteindre le même objectif mais une solution différente pour atteindre un objectif différent. Lequel de ces objectifs est le plus souhaitable pourrait être discuté.

5gon12eder
la source
1
Bien que la sémantique diffère entre les hachages et les horodatages, elle n'est généralement pas pertinente dans ce cas, car vous voulez très probablement une construction basée sur les fichiers actuels, quel que soit leur âge.
axl
La plupart de ce que vous dites est correct. Cependant, un système de construction bien implémenté qui utilise des hachages comme Google blaze / bazel (la version interne de blaze, l'open source est bazel) bat le pantalon d'un système horodaté comme Make. Cela dit, vous devez consacrer beaucoup d'efforts aux builds reproductibles afin qu'il soit toujours sûr d'utiliser les anciens artefacts de build plutôt que de reconstruire.
btilly
Le mappage ici n'est pas beaucoup à un, c'est un à un. Si Dmaintenant haché H2, et que vous n'avez pas de sortie T2construite à partir de D@H2, vous devez le produire et le stocker. Par la suite, quel que soit l'ordre dans lequel Dbasculer entre les états H1et H2, vous pourrez utiliser la sortie mise en cache.
Asad Saeeduddin
1

Le hachage d'un projet entier est très lent. Vous devez lire chaque octet de chaque fichier. Git ne hache pas chaque fichier à chaque fois que vous exécutez un git status. Les extractions VCS ne définissent pas normalement l'heure de modification d'un fichier à l'heure d'origine. Une restauration de sauvegarde le ferait, si vous prenez soin de le faire. La raison pour laquelle les systèmes de fichiers ont des horodatages est pour des cas d'utilisation comme ceux-ci.

Un développeur s'exécute généralement make cleanlorsqu'une dépendance non directement suivie par les modifications du Makefile. Ironiquement, cela inclut généralement le Makefile lui-même. Il comprend généralement également des versions de compilateur. Selon la façon dont votre Makefile est écrit, il peut inclure des versions de bibliothèques externes.

Ce sont les types de choses qui ont tendance à être mises à jour lorsque vous effectuez une mise à jour de contrôle de version, de sorte que la plupart des développeurs ont l'habitude d'exécuter un make cleanen même temps, de sorte que vous savez que vous commencez à partir d'une table rase. Vous pouvez vous évader sans le faire la plupart du temps, mais il est vraiment difficile de prévoir les moments où vous ne le pouvez pas.

Karl Bielefeldt
la source
Vous pouvez utiliser des systèmes de fichiers comme ZFS où le coût de hachage est amorti sur la durée de modification des fichiers, plutôt que d'être payé en une seule fois lors de la génération.
Asad Saeeduddin
1

Quelques points sur les hachages par rapport aux horodatages dans les systèmes de build:

  1. Lorsque vous extrayez un fichier, l'horodatage doit être mis à jour à l'heure actuelle, ce qui déclenche une reconstruction. Ce que votre collègue décrit n'est généralement pas un mode de défaillance des systèmes d'horodatage.
  2. Les horodatages sont légèrement plus rapides que les hachages. Un système d'horodatage n'a qu'à vérifier l'horodatage, tandis qu'un système de hachage doit vérifier l'horodatage et éventuellement le hachage.
  3. La marque est conçue pour être légère et autonome. Pour surmonter (2), les systèmes basés sur le hachage exécuteront généralement un processus d'arrière-plan pour vérifier les hachages (par exemple, Watchman de Facebook ). Cela va à l'encontre des objectifs de conception (et de l'historique) de Make.
  4. Les hachages empêchent les reconstructions inutiles lorsqu'un horodatage a changé mais pas le contenu. Souvent, cela compense le coût de calcul du hachage.
  5. Les hachages permettent de partager les caches d'artefacts entre les projets et sur un réseau. Encore une fois, cela compense largement le coût du calcul des hachages.
  6. Les systèmes de construction modernes basés sur le hachage incluent Bazel (Google) et Buck (Facebook).
  7. La plupart des développeurs devraient envisager d'utiliser un système basé sur le hachage, car ils n'ont pas les mêmes exigences que celles sous lesquelles Make a été conçu.
sdgfsdh
la source