cameleon-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Maxence Guesdon
Subject: Re: [cameleon-dev] TopMakefile.in et Makefile
Date: Sun, 13 Apr 2003 11:30:24 +0200

> * Sylvain LE GALL (address@hidden) wrote:
> > 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 ?

Ce n'est pas grave si plusieurs personnes modifient le Changelog, cvs
règlera le conflit lors du merge ou alors signalera le conflit s'il
ne peut etre résolu, mais dans ce dernier cas c'est très simple à gérer,
il suffit en gros de garder les lignes des uns et des autres.

> 
> Je pense qu'il faut changer le Changelog juste avant un commit (et c'est
> à chacun de se garder un chti memo de ce qu'il a fait). En fait, le
> mieux serait d'utiliser le message de commit de cvs comme Changelog (je
> crois que cela peut être fait automatiquement, je ne sais juste pas
> comment ;-).

Ben moi non plus ;-) De plus, est-ce que le message de commit est
suffisant ? Et puis aussi, il faut mettre à jour le fichier Changes.txt
pour indiquer les modifs visibles pour l'utilisateur (nouvelles fonctions
dans une lib, nouveau menu, ...)
 
> Au fait, c'est possible d'avoir une liste cvs (pour voir les commit qui
> ont lieu) ? Il faudrait que quelqu'un crée une liste sur Savannah, et
> après il faut faire (je vais chercher dans mon ficher pense-bête ...):
> 
> 1. cvs checkout CVSROOT
> 2. cd CVSROOT
> ...edit loginfo and add a line to the bottom like:
> xtatic mailx -s "CVS commit: %s" address@hidden address@hidden ...
> 
> 3. cvs commit
> 4. cd ..
> 5. rm -fr CVSROOT
> 
> Where I am assuming "xtatic" is the name of your cvs module.

Je vais faire ça. Attendez-vous à quelques commit bidons de ma part
pour tester ;-)

> > 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 :->. 
> 
> Je suis pour ocamlfind aussi. Il devient urgent que l'on se mette
> d'accord dans le monde caml sur un moyen de packager les librairies, et
> je trouve que ocamlfind est un bon outil. Il fait pas tout ce que je
> veux, mais c'est déjà pas mal.

En fait, j'avais dans l'idée d'attendre l'outil officiel de packaging pour
OCaml avant de changer. Si vous etes tous partant pour ocamlfind, allons-y
dans une branche d'abord puis dans le tronc commun quand ce sera ok.
Par contre, y a-t-il un moyen simple que ça marche avec ou sans ocamlfind?
Tant que ce n'est pas l'outil officiel, ça m'ennuie vraiment d'imposer
son installation; moi-meme ça me fait vraiment ch.... quand il faut
installer plein de prérequis.

D'ailleurs Alan, c'est pour bientot un outil standard de packaging ? ;-)

Maxence




reply via email to

[Prev in Thread] Current Thread [Next in Thread]