| 22 | | 1. Vous ajoutez une règle `synthesis:` avec une cible sans dépendance dans laquelle vous mettez la séquence des outils à lancer |
| 23 | | (boom, boog, loon, cougar, azimut, etc.). |
| 24 | | Cette règle est donc comme un script shell a l’instar des règles déjà présentes dans le Makefile. |
| 25 | | 2. Vous décrivez un Makefile dans lequel les règles ont la forme `fichier_produit : liste de fichiers sources`. |
| 26 | | Chaque règle ne fait qu’une étape de la conception ou de la vérification, une règle pour `boom`, une règle pour `boog`, etc. |
| 27 | | La seconde possibilité offre l’avantage d’être explicite du point de vue des fichiers produits et permet une reconstruction partielle. |
| 28 | | Mais elle est plus complexe à décrire et finalement pas très utile. Parce que l’intérêt principal du Makefile, c’est de décrire la |
| 29 | | séquence des outils et leur arguments, ce que fait mieux la première possibilité. En effet, c’est plus compact et donc plus simple à comprendre. |
| | 22 | 1. Vous ajoutez une règle `synthesis:` avec une cible sans dépendance dans laquelle vous mettez la séquence des outils à lancer (boom, boog, loon, cougar, azimut, etc.). Cette règle est donc comme un script shell a l’instar des règles déjà présentes dans le Makefile. |
| | 23 | 2. Vous décrivez un Makefile dans lequel les règles ont la forme `fichier_produit : liste de fichiers sources`. Chaque règle ne fait qu’une étape de la conception ou de la vérification, une règle pour `boom`, une règle pour `boog`, etc. |
| | 24 | La seconde possibilité offre l’avantage d’être explicite du point de vue des fichiers produits et permet une reconstruction partielle. Cependant, elle est plus complexe à décrire et finalement pas très utile. Parce que l’intérêt principal du Makefile, c’est de décrire la séquence des outils et leur arguments, ce que fait mieux la première possibilité. En effet, c’est plus compact et donc plus simple à comprendre. |
