Re: [Maitretarot-devel-fr] glib2; fichier de configuration; autoconf-2.5 et maitretarot

[Yves Mettier]

On 11 May 2002 20:18:16 +0200
philippe brochard <address@hidden> wrote:

> Yves Mettier <address@hidden> writes:
> 
> > On 11 May 2002 14:55:32 +0200
> > philippe brochard <address@hidden> wrote:
> > 
> > > Yves Mettier <address@hidden> writes:
> > > 
> > > > Coucou!
> > > > 
> > > > J'ai fait quelques modifications majeures sur tout ce qui ne touche pas 
> > > > le protocole de maitretarot.
> > > > 
> > > Chouette, moi je me met au travail pour ratrapper le retard de 
> > > mt_ncurses_client et
> > > mt_dolphin_ia.
> > > 
> > > > - glib-2.0: maitretarot utilise maintenant glib-2.0. Aucun changement 
> > > > n'a ete fait dans les sources. Les changements sont dans aclocal.m4 
> > > > (aclocal), configure.in (autoconf) et les Makefile.am (automake). A 
> > > > vous de reproduire les changements dans les interfaces utilisateurs ou 
> > > > IA si vous voulez.
> > > > 
> > > oui, pas de probleme, temps que c'est compatible avec la glib-1.2.
> > 
> > C'est compatible pour monter de glib-1.2 a glib-2.0. Enfin pour les trucs 
> > simples, c'est le cas. Inversement, il faut bien sur ne pas avoir utilise 
> > des trucs specifiques a glib-2.0!
> > 
> bon, pour la glib-2.0 voir messages suivant/precedent.

Vu.

[...]

> > > 
> > > Une question, la 2.13 et la 2.5 sont vraiment incompatible ?
> > 
> > La meilleure comparaison que je puisse faire est celle avec MS Word, 
> > versions 95 et 97 (je les connais un peu, mais pas beaucoup).
> > C'est compatible, mais quand on cherche a passer de l'un a l'autre, on se 
> > rend compte a quel point c'est pas tout a fait compatible.
> > Bref, le choix de Mandrake est pas mal: ils gardent les deux.
> > 
> Ouais, ça c'est un truc qui m'enerve prodigieusement, le fait de programmer
> sans pouvoir garder la compatibilité avec les anciennes versions. Ca pousse
> tout le monde à une course à l'échalote qui n'est pas toujours (rarement)
> justifiée.

Faut que ca se justifie.
habituellement passer d'une version d'un soft a une version superieure se 
justifie par le fait que la precedente version est rendue obsolete par la 
nouvelle. Et la compatibilite ascendente facilite un passage massif des applis 
vers le nouveau systeme. Pour glib-2.0, c'est a mon avis le cas.
La ou ca se corse, c'est quand il n'y a pas une vraie compatibilite ascendente, 
ou quand la migration est compliquee, ou encore quand la migration necessite de 
nouveaux outils. Avec autoconf, c'est le cas.

Enfin c'est mon avis, et rien n'empeche qu'on l'affine si on en discute ;-)

> 
> > > 
> > > > - La bibliotheque de fonctions de maitretarot: on aura config_utils.* 
> > > > et net.* dedans, et maitretarot.h pour le fichier d'en-tete. Je pense 
> > > > que personne n'y verra d'inconvenient. Par contre, au niveau des 
> > > > fonctions, il est imperatif de mettre un prefix devant chaque fonction. 
> > > > Je propose "mt_". Mais je ne sais pas si ce prefixe a deja ete utilise 
> > > > dans mt_ncurses_client ou mt_dolphin_ia. Est_ce que je peux utilise 
> > > > "mt_" ou dois-je prendre autre chose? Ainsi, "read_data()" deviendrait 
> > > > "mt_read_data".
> > > > 
> > > Oui, très bonne idée le mt_, mt_ncurses_client et mt_dolphin_ia ne 
> > > l'utilise pas.
> > > A vrai dire, il n'y a pas de prefixes du tout, il faut en mettre même si 
> > > ce
> > > sont des fonctions "locales à mt_dolphin_ia et mt_ncurses_client" ?
> > 
> > Pour les fonctions locales, y'a a mon avis deux cas: soit elles sont 
> > vraiment locales, et dans ce cas, pas besoin d'en mettre. Soit elles sont 
> > locales mais susceptibles d'etre reutilisees ailleurs, alors il vaut mieux 
> > mettre un prefixe.
> > 
> > D'ailleurs, je viens de changer d'avis. Pour la lib, ce ne sera pas mt_, 
> > mais libmt_ ou mtlib_.
> > Je prefere libmt_. Qui vote pour quoi?
> > 
> ouais, libmt_ c'est mieux (respect du standard des notations (cf /usr/lib)).

Arf, aucun rapport avec /usr/lib.
La lib s'appellera libmaitretarot.so a moins que quelqu'un ait une meilleure 
idee.
Ce sont les fonctions qui s'apppelleront libmt_trucmuche().
Et la, c'est pour que quand on appelle une fonction qui commence par libmt_, on 
sache d'ou elle vient. Tout comme les fonction commencant par gtk_ viennent de 
libgtk, ou celles commencant par g_ viennent de glib.
Et ca me lourde d'ecrire libmaitretarot_trucmuche a chaque fois, alors je 
prefere libmt_trucmuche a la place.


> > > > Derniere chose: je n'ai pas fait evoluer le protocole ni sa gestion 
> > > > depuis notre derniere coding-party.
> > > > 
> > > Ok, de toutes façons, il vaut mieux le tester avant de voir si il faut 
> > > modifier
> > > quelque chose -> je m'y met :)
> > 
> > Youpiiiiiiiiiiiiii!
> > 
> :)


Yahaaaaaaaaaaaaaa!
Vouiiiiiiiiiiiiiiiiiii!
Yepeeeeeeeeeeeeeeeeeeeeeee!
Heum ;-)


> 
> > > 
> > > 
> > > Une autre chose, par la suite, j'ai toujours envie de coder mon IA en 
> > > scheme,
> > > et ce que ça serait possible de recuperer mt_dolphin_ia pour l'ettendre 
> > > ou il
> > > faut que je me créé une nouvelle IA et qu'on developpe mt_dolphin_ia en C 
> > > ?
> > 
> > Alors la, ce n'est plus mon rayon. Nicoooooo!
> > 
> > Bah juste un petit truc quand meme. Il faut une IA de base qu'on peut 
> > etendre. Seulement, les deux doivent porter un nom different, et l'une doit 
> > avoir ses fonctionnalites figees, c'est-a-dire qu'elle ne soit pas etre 
> > etendue. A vous de choisir si mt_dolphin_ia est celle-ci, et dans ce cas, 
> > tu la recuperes mais tu mets un nouveau nom, ou si mt_dolphin_ia est une 
> > future "bonne" IA. Dans ce cas, il faut faire une autre IA simple pour 
> > servir d'exemple.
> > 
> ben, moi j'aimerai bien recuperer ma mt_dolphin_ia pour bidouiller qq chose
> en scheme (j'ai plein de trucs à tester :)
> 
> Donc ce que je propose :
> - on créer une IA de base : par exemple mt_base_ia

Ca, c'est un joli nom. Je vote pour!
Arf, non, je vote pas encore.
J'ai un autre candidat: mt_example_ia.

J'attends d'avoir des sondages et des commentaires avant de voter.
Mais l'idee est la.

> - je recupere mt_dolphin_ia

Oui.

> 
> - Nico, si tu veux develloper des trucs bien à part sans les mettrent
> dans l'IA de base, tu peut t'en créer une en repompant le code de
> mt_dolphin_ia (qui va être celui de mt_base_ia)
> 
> 
> s'en pensez quoi ?

cp mt_dolphin_ia mt_example_ia (ou mt_base_ia comme t'as propose)

Ensuite, Philippe, tu continues mt_dolphin_ia comme tu veux.
Nico, a toi de voir si tu bosses avec Philippe sur mt_dolphin_ia, si tu forkes 
mt_dolphin_ia, ou si tu repars sur mt_example_ia.
Je crois que j'ai rien dit de nouveau en fait (j'aurais du me taire?), a part 
qu'il faut choisir entre mt_example_ia et mt_base_ia pour le nom de l'ia qui ne 
doit pas evoluer afin d'etre un exemple simple.

Yves