> At 04:32 PM 4/16/2002 +0200, you wrote: > > je ne suis pas trop d'accord avec ce point de vue!!!
Eh, eh ! Heureusement, d'ailleurs, parce que sinon, il n'y aurait pas de raison de poser la question. > comment processer tes sources avec un tool du type iContract ou autre s'il > n'y a pas separation stricte en > src > src-instrumented > build > build-instrumented > etc... Bein.... Si je te dis que je n'utilise pas un outil de ce genre, �a t'�tonnera ? En fait, dans ce cas (et d'ailleurs, dans tous les cas o� diff�rentes sorties sont possibles) il faut clairement s�parer ces diff�rentes sorties dans diff�rents r�pertoires. Je prenais personnellement le cas o� aucun pr�processeur (ce qu'est iContract, il me semble) n'est utilis�. Dans ce cas bien pr�cis, qui concerne un bon nombre d'utilisateurs, la s�paration ne me semble pas une bonne id�e. > une structuration claire permet de: > simplifier les choses (build plus simple a ecrire) Mouais, encore une fois, �a n'est valable que dans le cas o� ton pr�processeur peut te fournir diff�rentes sorties. Si il n'existe qu'une seule sortie, la s�lection entre classes, jars et sources se fait tr�s simplement sur le type de fichier, et le build et d'une limpidit� exemplaire. Naturellement, tu me parleras du jour o� je souhaiterais passer � une instrumentation du code. Ce jour-l�, j'utiliserais (et je ne t'apprends rien) la possibilit� qu'offre Ant de sp�cifier le r�pertoire de sortie de la plupart des t�ches, li� avec une propri�t� bien sentie, pour placer les bons sources aux bons endroits. > etre sur de quel binaire tu utilises > pouvoir switcher de l'un a l'autre (au cas o� tu veuilles apres tests, > revenir a une version non instrumentee). > Jerome > Nicolas Delsaux
