Modalités de rendu (non contractuelles)
=======================================

Groupe de News:                 epita.cours.c++
Sujet de mail Yaka              [MINIMAKE]
Date de rendu:                  vendredi 7 mars 2003 - 12:00:00
Nom de l'exécutable:            minimake
Modalités:                      Ce mini-projet est à faire en monôme
Compilateur:                    g++-3.2
Tools:                          flex bison

Les informations ci-dessus peuvent changer jusqu'au 07/03/2003 12h00
La tarball compressée avec bzip2 devra s'appeler login-minimake.tar.bz2 
et se décompresser dans le répertoire login-minimake/.
Rappel : vous devez utilisez le flex et bison sur le compte d'Akim ainsi
que g++-3.2 des DP (ceci doit etre géré au niveau de votre PATH et non 
de votre Makefile).
En ce qui concerne les modalités de rendu veuillez vous reporter à la 
section Rendus située dans Infos->Modalités->Rendus du site yaka.
Attention votre projet doit compiler avec "GMAKE".


Introduction
============
Vous qui pensez encore que pour bien compiler un projet, il faut faire
un 'make clean all' ou bien pour les plus barbares un 'make re', à 
l'issue de ce miniprojet, vous saurez à quel point vous vous
mettez le doigt dans l'oeil!

Make, vous ne le savez peut-être pas, est très puissant. Il peut vous
faire gagner un temps précieux lors de la compilation (vous vous en
doutiez) mais aussi lors de l'exécution de tâches spécifiques,
ordonnées et dépendantes les unes des autres.  C'est à dire que par
exemple, pour construire une maison, il faut un toit, des murs, une
cave, des fondations, un maçon, et caetera.  Mais cela ne suffit pas, 
il faut en plus savoir qu'il faut des murs pour mettre un toit, qu'il 
faut des fondations pour faire des murs, un maçon pour commencer, et 
ainsi de suite...

Make sait, si on lui dit qui a besoin de qui, appeler chacun des
éléments dans l'ordre qui convient. Et mieux, si on lui dit comment
obtenir certaines choses à partir d'autres, il sait, quand il veut un
mur, qu'il faut appeler le maçon. Il sait aussi aller chercher les
briques pour faire un mur si on lui dit où elles se trouvent. Bref,
make sait faire plein de choses.


Objectif
========
Écrire un outil d'exécution de commandes en fonction de dépendances, à
la manière de make. Nous imposons que les fichiers acceptés par votre
programme soient acceptés par make. Le tout doit être implémenté en 
``vrai'' C++ (utilisation de l'héritage, de la stl ...).


Fonctionnement (rappels)
========================
Nous (YAKAs) osons espérer que c'est bien un rappel : make fonctionne 
en utilisant un fichier nommé Makefile où makefile dans lequel est 
décrit l'ensemble des règles du ou des projets à ``fabriquer'', ainsi 
que l'ensemble des dépendances entre ces règles.

Une règle est de la forme :
cible : [prérequis ... ]
[       actions]

ATTENTION : une action est précédée d'une tabulation, elle est
OBLIGATOIRE

Vous devez gérer au moins les options suivantes :

	- Les règles simples : c'est à dire à nom fixe, pas les règles 
	implicites, ni les règles à cibles multiples. Le fait de gérer les
	règles comme .c.o ou %.x : %.foo n'est pas obligatoire.

	- Les dépendances (évidemment). Les dépendances peuvent bien sûr
	être multiples. (cela inclut la détection des cycles dans les règles)

	- Les commandes, histoire que le programme fasse quelque chose.

	- L'option ``-f''. (Elle permet de spécifier que les règles sont
	dans un ficher autre que Makefile ou makefile.

	- Les commentaires 

	- Les variables simples avec l'opérateur d'affectation '=' et '+='

Attention, votre programme devra se comporter exactement comme ¨MAKE¨ 
(celui de NetBSD), c'est à dire qu'il ne devra pas utiliser de commande 
qui génère des fichiers déja à jour. En d'autres termes : ne pas exécuter 
de commandes dont la cible existe et dont les dépendances n'ont pas été 
modifiées.


Les variables
=============
En ce qui concerne les variables, il ne vous est pas demandé de faire 
la détection des cycles. De même vous n'avez pas à gérer le fait qu'une 
variable puisse être appelée avant même d'être définie :
LPATH = -L/usr/lib/ $(MLPATH)
MLPATH = -L.

En revanche vous devez gérer l'utilisation d'une variable dans la 
déclaration d'une autre variable : 
MLPATH = -L.
LPATH = -L/usr/lib/ $(MLPATH)

De même vous devez gérer les variables qui peuvent correspondre à des 
variables d'environnement : 
echo $(HOSTTYPE)

Vous n'avez pas à gérer les variables automatiques, exemple : 
$@
$%
CXX


Exemple simple
==============
foo.o: foo.c foo.h
	commande

Votre programme n'exécutera la commande que si la date de dernière
modification de foo.o est plus ancienne que celle de foo.c ou de foo.h


Exemple compliqué
=================
NAME	= minils
CC	= gcc
RM	= rm -f
CFLAGS	= -Wall -ansi
OBJS	= main.o \
	minils.o

IPATH	= -I.
MYLPATH	= -L.
LPATH	= -L/usr/lib/ ${MYLPATH}

LIBS	= -ltermlib
LIBS    += -ltermcap

all	: $(NAME)

$(NAME)	: ${OBJS}
	echo $(HOSTTYPE)
	$(CC) $(LPATH) main.o minils.o $(LIBS) -o $(NAME)

main.o	: main.c
	$(CC) $(IPATH) -c main.c

minils.o: minils.c
	$(CC) $(IPATH) -c minils.c

clean	:
	$(RM) main.o minils.o *~ \#*


En bonus
========
Cette section décrit les boni que vous pouvez implémenter. Ces boni ne seront 
corrigés que si la partie obligatoire fonctionne parfaitement. Ci-dessous une 
liste non-exhaustive des boni possibles :
	- Les variables (tout ce qui n'est pas demandé dans la 
	partie obligatoire)			==> MOT CLE : var
	- Les règles suffixes.			==> MOT CLE : suffix
	- Les règles implicites.		==> MOT CLE : imply
	- Tout ce qui vous plait dans make.	==> MOT CLE : other


Ce que vous pouvez utiliser
===========================
Vous devez utiliser des outils comme flex et bison, même si ce n'est pas 
indispensable. La STL et cela va sans dire sera indispensable. Vous devez 
utiliser make pour compiler votre projet. En revanche vous n'avez pas le 
droit à autoconf et automake.


Les fonctions
=============
Vous êtes invités à utiliser (à votre guise) les fonctions suivantes :
	- stat
	- fork
	- system
	- execve
	- les fonctions d'iostream
	- et ce qui [nv]ous plaira


La documentation
================
Les cours sur la théorie des graphes ainsi que la
documentation de make peuvent vous servir.


La tarball de rendu
===================
La tarball de rendu devra contenir obligatoirement les fichiers suivants
et sous cette forme. 

- AUTHORS
Prenom Nom	

- LINKS
 Contient :
#http://mon.site.web.interressant/
Titre Auteur

(Attention ne mettez pas de # dans les différentes descriptions)

- ChangeLog
 Contient :
AAAA-MM-JJ Prenom NOM :
	   * example.hh: fait ca

- TODO
 Contient :
La liste des choses qu'il reste à faire (ce n'est pas forcément vide...)

- Makefile
 Contient :
  - une règle "check" qui permet de lancer votre jeu de tests et signale les
tests problèmatiques.
  - une règle "all" et une règle "clean" qui font le travail classique que
l'on attend de ces règles. 
 
- Une compilation de votre projet devra générer à la racine de votre
  tarball un binaire nommé minimake (Si votre tarball contient le binaire que
  vous devez générer à la compilation, vous serez pénalisés)

- src/
 Répertoire contenant vos sources

- test/
 Répertoire contenant vos tests

Si vous faites des options (seul moyen d'être noté sur vos options) :
- OPTIONS
 Mettez une ligne contenant le mot clé spécifique à l'option, si ce n'est
pas fait ce n'est pas corrigé (Si une option implémentée n'a pas été prévue,
mettez le mot clé: "other", suivi d'une description brève de cette option).


Références
==========
http://netbsd.gw.com/cgi-bin/man-cgi?make++NetBSD-current
http://www.gnu.org/manual/make-3.80/html_mono/make.html