ca s'appelle l'audit de fabrication, c'est une information qui est stockée dans le repository.
Le problème c'est que dès que tu sors de ta vue (working copy) et que tu livres ton binaire, tu n'as plus cette trace.
Donc 2 solutions soit tu fais bien gaffe as toujours labelliser ce que tu livres soit tu utilise le technique de timestamping (marquage des executables) pour enregistrer toute l'arbre des dépendance dans ton binaires.
Autre avantage de clearmake. Clearmake est utilisé avec des vues dynamiques qui s'appuient sur un fs maison. Du coup toutes les accès à un fichier sont tracés? Donc quand tu compiles un .c qui fait apple à un include, clearmake detecte que le compilo ouvres le .h et ajoutes automatiquement dont une dépendance.
Du coup tu n'as plus besoin d'indiquer explicitement la dépendance dans ton makefile.
Autre avantage le partage d'objet dérivé. un binaire qui a déjà été compilé autre part dans le même contexte (même dépendance, mêm environnement) n'est pas regénéré mais directement recopié (lien symbolique) dans ton espace de travail (gain de temps et d'espace).
Tu as aussi, la compilation des cibles en parallèle.
Les inconvénients:
Clearmake n'est utilsable qu'avec les vues dynamiques qui sont connectées en permanence avec le serveur donc uitlsable qu'en LAN ou WAN musclé.
Avec les vues dynamiques tous les commits apparaissent instantanément (pas d'update) du coup ton environnemnt est suceptible d'être perturbé sans que tu le demandes (pb de correspondances des sources en debug, compil impossible, ....)
[^] # Re: A ce sujet...
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 5.
Le problème c'est que dès que tu sors de ta vue (working copy) et que tu livres ton binaire, tu n'as plus cette trace.
Donc 2 solutions soit tu fais bien gaffe as toujours labelliser ce que tu livres soit tu utilise le technique de timestamping (marquage des executables) pour enregistrer toute l'arbre des dépendance dans ton binaires.
Autre avantage de clearmake. Clearmake est utilisé avec des vues dynamiques qui s'appuient sur un fs maison. Du coup toutes les accès à un fichier sont tracés? Donc quand tu compiles un .c qui fait apple à un include, clearmake detecte que le compilo ouvres le .h et ajoutes automatiquement dont une dépendance.
Du coup tu n'as plus besoin d'indiquer explicitement la dépendance dans ton makefile.
Autre avantage le partage d'objet dérivé. un binaire qui a déjà été compilé autre part dans le même contexte (même dépendance, mêm environnement) n'est pas regénéré mais directement recopié (lien symbolique) dans ton espace de travail (gain de temps et d'espace).
Tu as aussi, la compilation des cibles en parallèle.
Les inconvénients:
Clearmake n'est utilsable qu'avec les vues dynamiques qui sont connectées en permanence avec le serveur donc uitlsable qu'en LAN ou WAN musclé.
Avec les vues dynamiques tous les commits apparaissent instantanément (pas d'update) du coup ton environnemnt est suceptible d'être perturbé sans que tu le demandes (pb de correspondances des sources en debug, compil impossible, ....)