La commande make permet de générer des fichiers et de les maintenir à jour
par rapport à leurs sources. Elle est configurée par un fichier toujours nommé
Makefile.
Nous allons produire Bake, notre propre version basique de cette commande.
Celle-ci utilisera un fichier de configuration Bakefile, qui respecte le
même format mais sans les éléments les plus complexes.
Vous produirez un programme écrit en Java, sans emprunt extérieur (sauf l'API officielle), et accompagné d'un rapport. Le travail sera fait en binôme ou trinôme, et devra être terminé avant le dimanche 16 mars 2025 à 23h59.
La partie logicielle sera développée dès le départ à l'aide du serveur Gitea du département. Le rapport prendra la forme d'un fichier au format PDF joint aux sources.
Le fichier de configuration Bakefile contiendra les règles de dépendance
pour chaque cible, avec la recette associée. Il pourra également contenir des
commentaires (commençant par #) et des affectations de variables
(uniquement avec le symbole =).
Une cible (ou une dépendance) est un chemin et doit donc pouvoir contenir tous les
caractères acceptables pour un chemin, en particulier / et ~.
Il n'est pas demandé de supporter les wildcards.
La seule cible spéciale permise sera .PHONY.
Une règle doit contenir une ou plusieurs cibles. La liste des cibles est terminée par le
caractère :, qui peut être collé à la dernière cible. Celui-ci est suivi par
la liste des dépendances, qui peut être vide.
Chaque règle est suivie d'une recette formée de zéro ou plusieurs lignes commençant
toutes par une tabulation. On supposera que le contenu de la recette est en language
bash.
Une affectation de variable est une ligne qui commence par le nom de la variable à
changer puis du symbole =. Tout ce qui suit constitue le nouveau contenu de
la variable, jusqu'à la fin de la ligne. Notez qu'une variable peut changer plusieurs
fois de valeur.
Pour les règles, les recettes et les affectations, un saut de ligne ne constitue pas la
fin d'une ligne s'il est précédé par un \.
Pour limiter le travail à accomplir, on ne gèrera pas les variables d'environnement, les variables automatiques, les fonctions, les règles implicites, les motifs de règles et les caractères spéciaux préfixes pour les recettes (voir le manuel de GNU Make).
Le programme acceptera en argument une ou plusieurs cibles à mettre à jour. Si aucune
cible n'est fournie, la première cible du fichier de configuration sera mise à jour. Les
messages affichés seront inspirés par ceux que produit make.
De plus, on pourra placer avant les arguments l'option -d, qui encourage le
programme à afficher des informations de déboguage durant son exécution :
Le programme devra avant tout lire le fichier de configuration en une seule passe. Pour
simplifier on substituera la valeur des variables au fur et à mesure de la lecture (ce
n'est pas le comportement normal de make).
Une fois la configuration chargée, le programme décidera des mises à jour nécessaires et exécutera les recettes correspondantes (via un ProcessBuilder). Lors de l'échec d'une recette, tout le programme doit s'arrêter.
Attention En cas de dépendance circulaire, le programme doit réagir pour éviter une boucle infinie. Toute dépendance envers une cible qui est déjà en cours d'évaluation sera donc ignorée.
Pour permettre de voir le comportement du programme dans une variété de situations, il vous est demandé d'inclure dans votre dépôt un certain nombre de cas de test.
Chaque cas de test comprendra un README de présentation, un fichier
Bakefile approprié, et le cas échéant des sources et des fichiers générés
(en C, en Java, ou complètement factices).
Parmi les situations à tester, vous devez inclure :
Les sources de votre projet (et pas les fichiers .class à
moins qu'ils ne fassent partie d'un test) devront être disponibles à tout moment sur le
serveur Gitea du département.
Votre dépôt sera privé, nommé obligatoirement SAE32_2024 et incluera Luc
Hernandez (login : hernand) dans la liste des collaborateurs. Le
nombre de soumissions, leur date et l'équilibre entre leurs auteurs influeront sur la
note finale.
Pour chaque classe, vous prévoierez un fichier source. Suivez les
consignes habituelles
scrupuleusement. La définition de chaque classe et de chaque membre de classe sera
précédée d'un commentaire formaté pour permettre la génération de documentation technique
par l'outil javadoc (ceci est
un exemple de fichier source bien commenté).
Vous devrez respecter l'organisation du code vue au début de l'année. Toutes vos classes
appartiendront à un package. Un fichier Makefile devra permettre la
compilation de votre projet et la création d'une archive jar. Transcrivez bien
toutes les dépendances entre vos fichiers dans les règles.
Le rapport d'avancement prendra la forme d'un fichier PDF disponible avec les sources sur le serveur Gitea. Vous y inclurez en particulier :
Soignez la présentation ! L'orthographe, la grammaire, les pages de garde, la table des matières, les en-tête et pieds de page ne sont pas en option...
Notez bien que le rapport ne doit pas contenir d'extrait du code source du projet, étant donné que le correcteur peut aller le consulter directement s'il en éprouve le besoin. N'hésitez pas en revanche à illustrer vos propos par des schémas. Ceux-ci peuvent être construits directement dans le logiciel de traitement de texte s'il le permet, ou dans un logiciel dédié, tel que Inkscape ou Draw (tous deux gratuits). Les diagrammes de classe et d'objets seront réalisés à l'aide de StarUML.