RE: [Tsp-devel] Ant+TSP: ca commence à gigoter

[Eric.NOULARD]

Je ferais une réponse + longue + tard
ma version courte est:

  - je suis POUR dégager les makefiles pour Java
    [car la double maintenance Makefile + buildfile
     va être très pénible]
  - les tar.gz 'binaires' et autres jar sont des produits de compils
    autrement dit des "livrables" qui doivent être
    1) installables (+ éventuellement configurable)
    2) utilisables
    Il faut (je pense) les générer 'HORS' arbo sources CVS
    et les déposer dans la partie 'Files' de Savannah
    Je pense qu'il faut définir le contenu et les procédures
    de création de 2/3 livrables pour le C et Java de façon
    à ce que quelqu'un qui veut juste 'utiliser' et pas développer
    puisse le faire.
    Bref des paquetages 'binaires'.

Ce sera [je pense] très utile au déploiement de TSP que ce soit
en Java ou en C d'avoir des version binaires dispos, d'autant
que même en C avec le BB tu peux développer un provider TSP
sans même compiler 1 seule ligne de l'arbo TSP.

Je fais un mail plus long dès que possible.
Eric

-----Original Message-----
From:   address@hidden on behalf of Stephane Galles
Sent:   Mon 10/25/2004 6:03 AM
To:     tsp-devel
Cc:    
Subject:        Re: [Tsp-devel] Ant+TSP: ca commence à gigoter

NOULARD Eric wrote:

>[...]
>peut-être que le configure pourrait suggérer la définition
>de JAVA_HOME au même moment ou il détecte la conf java
>disponible ?
>
>Je sais que c'est un peu plus l'affaire de celui qui
>a installé Java ou Ant de se positionner le JAVA_HOME
>mais le configure aurait du gueuler non?
>
>Ou alors on postule que configure ne doit également
>pas être utilisé pour Java??
> 
>
Effectivement, j'ai moi aussi l'impression qu'on devrait converger
vers la situation suivante :
- Les makefiles s'occupent du C
- Les Antfiles s'occupent du JAVA
Et on se débarasse des Makefile qui gèrent encore du Java

En effet, m'explique :

1 - Si une personne souhaite utiliser/essayer, sans développer, des clients
JTsp, elle n'a besoin ni de ant, ni de make, car à la différence
du C, on peut fournir des packages déjà tous compilés (il n'y a pas
besoin de recompiler en fonction de la plateforme pour simplement
executer un truc)

2 - Si une personne souhaite développer de nouvelle choses dans
JTsp, alors je pars du principe qu'elle utilisera Ant, ou un IDE, ou
bien les deux... Mais pas , surement pas, des makefile, dans tous les cas.
Une personne qui souhaite serieusement développer en Java va prendre
deux secondes pour installer Ant.

3 - Si des développeurs Java pur voient qu'il faut qu'ils mettent leur
nez dans du configure ou du makefile, ils vont partir en courant

Je ne pousse pas au débarquement des Makefiles gérant le Java, en fait
cela m'est complétement égal. Le problème est juste qu'à la lumière
de ces 3 points je ne vois pas à quoi peuvent encore servir les makefiles

En tous cas, que les Makefiles restent ou pas pour le Java, je me charge
d'ajouter des taches Ant pour exporter des kits en .tar.gz de Jstp,
ainsi que
de Jsynoptic, afin de les proposer aux gens qui n'ont que Make, pas Ant,
mais qui veulent tester la partie Java sans installer Ant.
ces tar.gz contiendront des scripts .sh et .bat pour lancer les clients
quelque soit la
plateforme (Windows/Unix).

J'ai juste besoin de votre avis pour un point que je ne sais pas trancher :

Dois je géner les tar.gz :
- Dans le partie DEV de l'arbo ? dans ce cas il faudra prendre ces
tar.gz et les proposer en téléchargement dans la partie Files de Savannah
de temps en temps.
- Dans la partie CVS de l'arbo ? Dans ce cas, quand des sources ont été
modifiés, il suffira de  regéner les tar.gz avant de faire un commit
(c'est un moyen de proposer un snapshot précompilé des sources avec les
sources
dans CVS)

Qu'en pensez vous ? Est ce une bonne idée au moins ?

>
>
>
>En tout cas c'est cool ant,
>j'ai bien envie de regarder ce que ça donnerait pour le C...
>mais pas tout suite avant j'ai d'autre truc sur ma liste.
>
C'est possible, mais sache que cette partie de Ant est beaucoup moins
aboutie que celle pour Java (en particulier il faut ajouter des taches
optionnelles : http://ant-contrib.sourceforge.net/cc.html ).

Le problème est que Ant n'est pas aussi souple qu'un Makefile, ce n'est
pas la même philosophie, Avec Ant du associe des macro éléments, les taches,
et quand il te manque une tache, tu ne peux pas la coder dans Ant,
ce n'est pas un language de script.
Il faut que tu code ta tache en Java et tu la plug dans Ant.
C'est ce qui fait la robustesse de Ant, c'est ce qu'il fait aussi qu'il
faut avoir
toujours les meme taches à faire pour que cela fonctionne bien.
Mais bon, si le projet C que tu veux compiler est suffisemment structuré,
cela peut être possible.

Steph

>
>Eric
>
>Le sam 23/10/2004 à 04:07, Stephane Galles a écrit :
> 
>
>>Bien,
>>
>>J'ai fait ce dont nous avions parlé, maintenant notre build.xml génère un
>>repertoire jar, avec :
>>
>>./jar/tsp-consumer.jar
>>./jar/README
>>./jar/consumers
>>./jar/consumers/README
>>./jar/consumers/jsynoptic-tsp-plugin.jar
>>./jar/consumers/jstdout.jar
>>./jar/consumers-bundle
>>./jar/consumers-bundle/README
>>./jar/consumers-bundle/jsynoptic-tsp-plugin-bundle.jar
>>./jar/consumers-bundle/jstdout-bundle.jar
>>
>>De plus j'ai ajouté deux taches qui fait qu'il est beaucoup plus facile
>>de lancer des clients.
>>Genre, on se place dans le repertoire tsp, on lance ant une fois pour
>>compiler (sans arguments),
>>puis :
>>
>>ant jsynoptic-run
>>permet de lancer ... jsynoptic
>>
>>et
>>
>>ant jstdout-run
>>permet de lancer ... jstdout
>>
>>J'ai testé un peu tout ça, ça a l'air de fonctionner pas trop mal.
>>
>>Bon...maintenant je passe aux exceptions et URL...
>>
>>Steph
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>Tsp-devel mailing list
>>address@hidden
>>http://lists.nongnu.org/mailman/listinfo/tsp-devel
>>   
>>



_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel