Utilitaire de compilation Bake

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 19 janvier 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.

Fonctionnalités

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.

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 :

• quel fichier est considéré pour une mise à jour,
• quelle comparaison de dates est faite et quel résultat est obtenu,
• quel fichier va être régénéré.

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 =).

La seule cible spéciale permise sera .PHONY.

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 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.

Tests

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 (entre 4 et 8).

Chaque cas de test comprendra un README de présentation, des sources (en C ou en Java), un fichier Bakefile approprié, et des résultats partiels ou complets de compilation.

Parmi les situations à tester, vous devez inclure :

• une compilation depuis rien,
• une compilation où le résultat existe déjà,
• une compilation où un résultat existe déjà, mais une source a été modifiée,
• une compilation où une dépendance circulaire est présente.

Sources

Les sources de votre projet (et pas les fichiers .class) 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.

Rapport

Le rapport d'avancement prendra la forme d'un fichier PDF disponible avec les sources sur le serveur Gitea. Vous y inclurez en particulier :

• le nom des membres du groupe,
• une introduction contenant une brève description du sujet,
• la description des fonctionnalités de votre programme, aidée de captures d'écran,
• une présentation de la structure du programme, avec diagramme de classes simplifié à l'appui,
• une explication des classes participant au graphe des dépendances,
• une exposition de l'algorithme qui détecte les dépendances circulaires.
• une énumération des structures de données abstraites vues en cours utilisées dans votre projet,
• une conclusion personnelle pour chaque auteur.

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.