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

[Sylvain LE GALL]

Salut,

On Sat, Apr 12, 2003 at 11:00:04AM +0200, Maxence Guesdon wrote:
> > 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 ?
>  

Bien sur.

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

Pas de probleme : on fait un Makefile.exec Makefile.libs Makefile dans
Makefile :
all:
        make -f Makefile.libs all
        make -f Makefile.exec all

> > 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 :-)

Ben pour moi les dépendances entre outils c'est la variable REQUIRE =
report  par ex ( ce qui veut dire qu'on as besoin de la lib report )

Pour la reconstruction des bibliothéteques, il y a un moyen : vérifier
que les fichiers installé sont a jour avec les fichiers potentiellement
générable dans le rep. C'est un poils plus complexe que mon makefile un
eu simpliste mais ca peut se faire.

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

Oui effectivement, il faut mettre un truc pour descendre dans le
répértoire et un Makefile dans le répértoire. C'est vrai que ca peut
etre limiter d'un point de vu intérêt.

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

C'est clair que pour tout ce qui n'est pas libs, il faut faire le manuel
de l'utilisateur.


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

Je me pose beaucoup de question sur les changelogs en fait, c'est le
fichier merdique de toute une distrib : je travaille sur ocamlcvs et toi
sur zoggy, on édite tout les deux changelog : conflit de version.
Comment on peut gérer ca. Peut etre qu'un fichier par personne peut etre
un solution ?

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

C'est dommage : ocamlfind c'est un bon outil. Ca permet d'intégrer trés
rapidement plein de truc sans avoir à se soucier des dépendances et tout
et tout. Au début j'était pas trés chaud non plus et j'ai découvert ca
avec PXP ( qui sans ocamlfind serait trops complexe à manipuler ).
Accessoirement, et sans autorisation d'ailleurs, il me semble que toute
les bibliothéque de cameleon sont ocamlfindiser sur la debian :->. 

Pour l'intéret je suis d'accord que ca peut etre limiter. De mon point
de vue c'est séparer la compilation clairement : de temps en temps (
prendre l'exemple de epeire ) il y a des dépendances entre des fichiers
de code et d'autre fichiers de code d'un autre répértoire. Si on inclue
le répértoire, plus de probleme : toute les dépendances sont satisfaite
puisque tout est ouvert. Mais si il y a des gens qui préfére exporter de
.h ou .mli c'est que desfois, il faut pas trop mettre les mains dans le
cambouilli ( on ne s'attache qu'au .mli et pas à l'implémentation ).
C'est le principe d'utiliser un répértoire de pseudo installation qui
permet de faire tampon de facon à maitriser ce qui est exporter de telle
et telle répértoire.

Ca se discute et je vous propose de voir ca la semaine prochaine quand
j'aurais changé deux trois trucs ( dans un patch ou une branche séparé
).

Bon week end
Sylvain LE GALL