Re: [cameleon-dev] TopMakefile.in et Makefile

[Maxence Guesdon]

> Je l'avais envoyer me je peux me tromper...

Je l'avais pas eu...

> Eventuellement on commit en taggant proposed-patch-by-gildor-0.1. Comme
> ca on garde la branche principale et on merge la branche si c'est bon.

Oui, en utilisant des branches ça marche aussi mais c'est plus lourd
(enfin, surtout pour celui qui les fait :-)
 
> > Ok. Attention, il est important de tester, surtout dans l'optique de ne pas
> > faire perdre de fichiers à l'utilisateur.
> 
> Non, non c'est juste des trucs du genre cvs -R ( recursif quoi ) + une
> liste des récents + menu contextuel... Je touche pas à la base.

Ok, pas de pb, on attend ça avec impatience...

> Je vous joint TopMakefile.in et deux Makefile.
> 
> TopMakefile.in se met dans le root du projet. quand on fait ./configure
> ca génére TopMakefile avec tout ce qui va bien ( en particulier
> modification de OCAMLPATH et TEMPBUILDLIB ).

On peut utiliser le nom master.Makefile.in, qui existe déjà et que
j'aime mieux ?
 
> Ensuite chaque Makefile se met dans un rep et peut générer un executable
> ou une librairie. 

Y'a plusieurs outils qui font plusieurs exécutables + 1 bibliothèque dans
le meme répertoire (par exemple: report). 
C'est possible avec ton système ?
 
> Si c'est un executable on link avec les require : soit des choses
> installé sur le systeme, soit des choses que l'on vient de construire
> dans un autre répértoire et qui se sont installés eux memes dans
> root/.libs.
> 
> Comme ca tout est assez claire : les dépendance entre les paquets sont
> satisfait si les objets qu'il faut sont dans la variable INSTALLIB. On
> ne gére plus du tout les liens interéptoire qui sont assez complexe. Ca
> permet de faire des frontière nettes entre paquets ( et ca facilite la
> vie des packageur qui n'ont qu'a changer destdir pour installer les
> différentes libs ). 

La variable DESTDIR est déjà gérée (dans master.Makefile.in, définition
de LIBDIR, BINDIR, ...).
La séparation entre paquets est déjà assez visible, meme si elle
peut etre améliorée, il suffit de regarder les LIBS, LIBS_GUI utilisés
dans le Makefile de chaque répertoire pour voir ce qui est utilisé.
Par contre, ça ne les recompile pas si elles n'existent pas, mais ton
système non plus. D'autre part, n'oublions pas que la compilation
de cameleon est faite séquentiellement, donc si il manque des trucs
qui n'ont pas été compilés: make clean ; make all
C'est brutal mais simple. Je ne pense pas que cela soit la peine
de changer si on n'a pas un système qui recompile, par exemple, les 
bibliothèques requises par report si elles ne sont plus à jour ou
pas là.
De plus, les bibliothèques générées dans cameleon sont définies 
dans master.Makefile.in, et on utilise ces variables pour les utiliser
dans le Makefile de chaque répertoire. Comme ça on se soucie pas de savoir
où elles sont.
 
> Je sais que c'est plus simple de tout inclure et d'y aller à la barbare
> en incluant tout, mais je trouve que c'est générateur d'erreur : on
> finit par avoir des liens entre 15 rep et on ne sait plus qui utilise
> quoi. Avec mon système : un rep = une lib independante ( ou plusieurs si
> on met différents makefile par rep faut voir ).
> 
> Ca a le gros avantage de rendre le système vraiment modulaire...

Je ne suis pas vraiment convaincu. Pour etre modulaire, il faut
avoir les dépendances entre outils qui permettent de reconstruire
ce qu'il faut. Si ça vérifie juste que la lib requise est présente,
ça le fait déjà, vu que la compilation plante :-)
Etre modulaire, pour moi, ça voudrait dire qu'on ajoute un répertoire
et rien d'autre. Là il faut tout de meme mettre dans le Makefile
à la racine qu'il faut descendre dans chaque répertoire et compiler.
Ou alors j'ai raté quelque chose ?
 
> ( Tout ca se discute, je ne suis pas G W Bush, moi ;-> ).

Moi non plus en fait, heureusement ! Et j'ai aucun lien de parenté, non
plus :-)
 
> Moi je crois beaucoup à ocamldoc ;->. C'est bien fait et ca permet de
> joindre le code avec la doc.

OCamldoc ne suffit pas pour faire le manuel utilisateur. Mais je
suis d'accord qu'il fait faire la doc du code en meme temps que le code.
 
> Si tu parles de facons plus générale des HOWTO, c'est plus complexes. Je
> pense qu'une semaine avant une release on dit qui s'occupe de quelles
> sections ( en fait les gens s'occupent de la section qu'ils ont modifé
> depuis la dernière release ). 

Oui, d'où l'intéret de bien enrichir le fichier ChangeLog pour savoir
ce qui a été modifié depuis la dernière release.

> J'attends vos réactions sur les Makefile. Si vous étes d'accord je m'en
> occupe la semaine prochaine ( j'ai un mariage ce WE ).

Dernier point, je ne suis pas très chaud pour avoir à installer
ocamlfind...
En bref, je suis pas trop d'accord. Tu peux le faire dans une branche
séparée, comme ça on pourrait regarder si ça apporte vraiment
quelque chose ?

Bon mariage !

Maxence