Discussion :

[waterbed]

Bonjour,

Le probleme est le suivant j'ai un projet sous eclipse avec plsueirs packages, en temps normal je laisse eclipse se charger de la compilation, le hic est que je souhaite à présent compiler moi même mes classes. Voici ma version, qui marche mais que je trouve "immonde", je suis sûr qu'il existe un moyen plus propre de faire ça... (sans utiliser ant )

${JAVAC} -d build -sourcepath org -classpath lib/jdom.jar:build org/test/gui/*java org/test/newModJk/*java org/controler/*java org/responder/*java org/tools/*java org/controler/exceptions/*java org/responder/exceptions/*java ; cd build

Merci à tous

[iohack]

Pourquoi trouves-tu cela immonde ? Je procède généralement comme ceci sous OS AIX ( il n'y a pas d'éclipse ) .

[waterbed]

Très honnêtement je pense/pensais qu'il existe un autre moyen technique par exemple :

javac -d build -sourcepath org -classpath lib/jdom.jar:build org/test/gui/*java NomDeLaClasseAyantUnMain.java

[iohack]

Pas à ma connaissance en tout cas. Cela dit, si ça existait effectivement, ce serait un peu plus propre quoique dangereux car on ne maitriserait les classes à compiler. Que ce passerait-il si on souhaite ne pas compiler un package...

[bouye]

Il est possible de lister (recursivement) le contenu du repertoire des sources (via un autre programme (Java ou pas) ou un script bash) et de le passer au compilateur via le flag @ (qui fait que le compilateur prend en entree le contenu du fichier specifie).

Avant de passer sous ANT et plus tard sous JBuilder j'utilisais le fichier batch suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
@ECHO OFF
cls
REM deltree /y .\org
rmdir /s /q .\org
dir /S /B /O:N src\*.java > Files.txt
javac -deprecation -g:none -O -classpath . -d . -sourcepath src @Files.txt

[iohack]

enfin ce truc a ses limites, si tu modifies deux classes qui interagissent ensemble et que c'est la mauvaise qui est compilée en premier, tu te retrouves avec une erreur de compilation qui ne devrais pas être à la vue de ton code source...
En gros il faut respecter l'ordre de compilation en commençant par les classes de bas niveau ( qui n'utilisent aucune autres classes que celles du JDK ) vers celles de haut niveau.
La seule solution efficace que j'ai trouvée est de créer un certain nombres de ksh ( test des codes retour, environnement etc. ) et de compiler chaque classe dans l'ordre que j'ai défini.

[bouye]

Geuh ?! On a pas les problemes de dependances de C/C++ la ...
Dans ANT j'avais des dependances car j'avais definis des sous-modules de mon app et donc il fallait les compiler dans l'ordre. Mais c'etait juste une division artificielle du projet.

Mais dans la mesure ou tu passes a javac une liste complete de toutes les classes a compiler, il se contrefiche de l'ordre et gerera/resoudra tout de lui-meme.

Par contre ce qui peut arriver c'est que si tu as des constantes (final) elles soient "inlinees", c'est a dire que leur valeur est recopiee "en dur" dans le bytecode des classes appelantes au lieu d'avoir des references a resoudre a l'execution, histoire de gagner du temps d'execution. Donc dans ce cas il ne suffit pas de recompiler uniquement la classe/interface dans laquelle cette constante est definie. Cela peut engendrer des problemes (les anciennes versions de Java ne faisaient pas d'inlining cependant) ; ce probleme n'est pas propre a Java et existe aussi dans d'autres languages.

De toute maniere dans bien des cas Java compile plus rapidement que le C++, c'est donc moins genant de recompiler l'integralite du projet. Ensuite les IDE gerent en general bien les problemes de constantes redefinies histoire de compiler le moins de choses possible.

[iohack]

humm tu dois avoir raison, mon problème doit être du au fait que je compile chaque classe séparément en invoquant à plusieurs reprise javac... vais tester ça cet après-midi..

EDIT : Testé et confirmé

[bouye]

Dans le cas, je crois qu'il vaux mieux utiliser ANT puisqu'on peut definir des dependances comme dans un Makefile. Ou alors faire un tres long script/batch.