On voit que tu n'as jamais travaillé sur un gros projet.
si, ce que je vois moins ce sont ces préjugés récurrents...
L'avantage, c'est que les clients d'B, qui incluent B.h,
j'ai mal lu le "client de", ton point était et est exact.
(Note que techiquement, si j'ajoute une fonction non-virtuelle à A, il n'y a pas vraiement de raison à avoir à récompiler les clients d'A qui n'ont changé. Mais les systèmes de make actuel ne permet pas de faire cette distinction.)
un make pur sucre non, des outils avec "gestionnaire-à-eux" le détectent assez bien (studio par exemple qui n'utilise pas que la date du .h mais détecte les modifications réelles de la définition).
Sylvain.
kanze wrote on 22/06/2006 09:14:
On voit que tu n'as jamais travaillé sur un gros projet.
si, ce que je vois moins ce sont ces préjugés récurrents...
L'avantage, c'est que les clients d'B, qui incluent B.h,
j'ai mal lu le "client de", ton point était et est exact.
(Note que techiquement, si j'ajoute une fonction non-virtuelle à
A, il n'y a pas vraiement de raison à avoir à récompiler les
clients d'A qui n'ont changé. Mais les systèmes de make actuel
ne permet pas de faire cette distinction.)
un make pur sucre non, des outils avec "gestionnaire-à-eux" le détectent
assez bien (studio par exemple qui n'utilise pas que la date du .h mais
détecte les modifications réelles de la définition).
On voit que tu n'as jamais travaillé sur un gros projet.
si, ce que je vois moins ce sont ces préjugés récurrents...
L'avantage, c'est que les clients d'B, qui incluent B.h,
j'ai mal lu le "client de", ton point était et est exact.
(Note que techiquement, si j'ajoute une fonction non-virtuelle à A, il n'y a pas vraiement de raison à avoir à récompiler les clients d'A qui n'ont changé. Mais les systèmes de make actuel ne permet pas de faire cette distinction.)
un make pur sucre non, des outils avec "gestionnaire-à-eux" le détectent assez bien (studio par exemple qui n'utilise pas que la date du .h mais détecte les modifications réelles de la définition).
