stl::vector - Page 3

Bah, le seul mot italien dans cette expression, c'est "mano". On dit "a mano" en italien, pas "alla mano" et encore moins "à la mano".

PpHd (./59) :
Donc la question que je te pose: comment je remplis mon fichier Makefile avec tous les dépendances systèmes ?
Avec une ligne dans mon Makefile
CC=$(shell which gcc || which gcc42 || which cl || which cc)
?

Dans le makefile de ld-tigcc, j'ai:
CC=gcc
tout simplement.

Si je cross-compile, je fais:
make OSTYPE=msys CC=i386-mingw32-gcc

PpHd (./59) :
Tu sais avec les autotools tu peux compiler avec MSVC. Même que c'est officiellement supporté. (Dans mes souvenirs, c'est ./configure CC=cl.exe ...)

Oué enfin quitte à ne pas être portable, si j'utilise MSVC, c'est pas pour aller taper des lignes de script; je clique simplement sur "Compiler" :]

(deuxième paragraphe zappé, je n'ai pas su déterminer si il y avait une question ou si c'était juste inutile)

A le rigueur, tu prends Makefile.in et tu fais tous les replace all nécessaire avec les valeurs détectées par ton configure manuel (tu sais le papier et le crayon). Ca sera aussi bien.N'empéche que make ne marchera pas tout seul. Il lui faut au minimum un compilateur et un linkeur.

Que je suis libre de choisir, bis repetita. (indice : post ./55)

Zephyr (./63) :
Que je suis libre de choisir, bis repetita. (indice : post ./55)

Libre de choisir comment? Dans mes makefiles, CC=gcc est codé en dur et je ne vois pas trop comment faire autrement.

Kevin Kofler (./64) :
Libre de choisir comment? Dans mes makefiles, CC=gcc est codé en dur et je ne vois pas trop comment faire autrement.

Bah oui, mais au pire je peux éditer ton fichier et changer la ligne "CC=" en ce que je veux; c'est une ligne à changer, ça reste minime. Si le projet utilise des autotools, je n'ai aucune alternative.

(Au passage, ld-tigcc ne compile pas avec autre chose que GCC et ça ne va pas changer. La seule raison valable pour mettre un autre CC dans son makefile est d'avoir un GCC nommé autrement, par exemple un cross-compilateur. Mais ce n'est pas dû au makefile, mais au code source.)

Kevin Kofler (./61) :

Bah, le seul mot italien dans cette expression, c'est "mano". On dit "a mano" en italien, pas "alla mano" et encore moins "à la mano".

Ok, je note.

Zephyr (./63) :

Que je suis libre de choisir, bis repetita. (indice : post ./55)

Ben avec un fichier script configure aussi ! Et même que c'est plus simple.

J'ai quel choix pour exécuter le script configure sous Windows ?

MSYS ou Cygwin.
Peut-être même SFU/Interix d'ailleurs...

Peut être çà: http://www.microsoft.com/technet/community/events/windows2003srvr2/add-52.mspx

Windows Server 2003 ? /me XP

Il y a aussi un SFU pour XP.

Heu et ant?
Non parce que là où je bosse ils utilisent ça font (ils font pas mal de cross compile etc...).

D'ailleur si qqn connait ant je serais ravis d'avoir un petit cours!

+1

Déjà c'est du Java. Ensuite tout est en XML. Je préfère encore les autotools.

En même temps, si c'est pour faire des remarques de si bas niveau, tu peux t'abstenir!

Et pourtant, force m'est de reconnaitre que je trouve contre-nature d'utiliser du java pour builder du C ou du C++...

Et pourtant, force m'est de reconnaitre que je trouve contre-nature d'utiliser du java...
quoi de mieux en rentrant de vacances qu'ajouter un peu d'huile sur un troll

Make est fait en C et personne ne trouve contre nature de l'utiliser pour autre chose que du C, donc je vois pas pourquoi on ne pourais pas utiliser quelquechose en Java pour builder du C.

Après c'est vrai que la syntaxe XML n'est pas évidente au premier abord. Mais si le fait d'avoir un outil de build vraiment multiplateforme t'intéresse, ce n'est qu'un détail. que tu auras vite dépassé.

histoire d'habitude, comme tous les outils logiciels.

Uther (./79) :
Mais si le fait d'avoir un outil de build vraiment multiplateforme t'intéresse, ce n'est qu'un détail. que tu auras vite dépassé.

Je serai quand même curieux de voir ce que ca donne sur un bon vieil HP UX qui date de 1995 qui a été mis à jour et qui m'arrive d'utiliser
Parce qu'on a beau les critiquer, les autotools marchent très bien sur tous les systèmes (même windows si on ne fait pas de fixation à la Vertyos de ne jamais rien installer).

Si ta machine est capable de faire tourner une JVM Java, ça devrait marcher.
Maintenant, c'est vrai que ant n'est portable qu'a condition qu'une machine virtuelle soit utilisable sur la plateforme.

Ou que GCJ gère le target.

A condition aussi que GCJ implémente tout ce qu'il faut pour faire tourner ant, ce qui n'est malheureusement pas encore garanti.

./82> Qu'une machine virtuelle compatible tu veux dire. Parce que chaque implémentation de machine virtuelle a son jus d'incompatibilités avec celle de Sun.
JBoss, Weblogic, Borland AS, Sun, Websphere... chaque serveur d'appli ou presque a sa propre implémentation, et au final une application JBoss ne fonctionnera que sous JBoss, une application Weblogic ne tournera qu'avec Weblogic, etc. Et c'est pas qu'une question de libs hein, il y a des incompatibilités même sur les trucs qui font partie des "specs" J2EE.

Et sans aller jusqu'aux serveurs d'applications, même en restant sur les postes de travail, les JVM de Microsoft, de Sun, d'IBM, et de Apple pour ne citer que les plus utilisées, ben je te mets au défi de faire une application un tant soit peu complexe qui tourne impeccable sur les 4 sans introduire de tests spécifiques (si je tourne sur le JVM Microsoft, alors faire ça, si je tourne sur celle de Sun, alors faire ça, etc...)

Les problèmes de compatibilité ont été déplacés du matériel à l'implémentation de la JVM, mais ils sont toujours là. Et comme chaque JVM ne propose qu'un nombre limité de plateformes matérielles...

Uther (./84) :
A condition aussi que GCJ implémente tout ce qu'il faut pour faire tourner ant, ce qui n'est malheureusement pas encore garanti.

ant-1.6.5-4jpp.2.fc7 tourne très bien avec GCJ.

microsoft a une vm? Il me semblait qu'ils recommandaient celle de sun non?

Ils en avaient une basée sur Java 1.1, ils ont été obligés à l'abandonner par Sun (il y a eu un procès) parce qu'ils ne respectaient pas la licence (ils ont rajouté des trucs non-standard). C'est ça qui a mené au développement de C#.

D'ailleurs, je me demande si M$ pourrait refaire un JVM basé sur OpenJDK maintenant ou si les clauses de leur accord (qui a terminé le procès) sont telles qu'ils n'ont pas le droit. Enfin bon, je pense que M$ n'a de toute façon pas envie de travailler avec la GPL.

spectras (./85) :
Qu'une machine virtuelle compatible tu veux dire. Parce que chaque implémentation de machine virtuelle a son jus d'incompatibilités avec celle de Sun. JBoss, Weblogic, Borland AS, Sun, Websphere... chaque serveur d'appli ou presque a sa propre implémentation, et au final une application JBoss ne fonctionnera que sous JBoss, une application Weblogic ne tournera qu'avec Weblogic, etc. Et c'est pas qu'une question de libs hein, il y a des incompatibilités même sur les trucs qui font partie des "specs" J2EE.

Certes la compatibilité 100% n'existe pas, mais en JAVA les incompatibilité sont en quand même relativement rare et le plus souvent mineures. Pour une application console comme ant, il y a peu de chance d'avoir ce genre de problème.

spectras (./85) :
Et sans aller jusqu'aux serveurs d'applications, même en restant sur les postes de travail, les JVM de Microsoft, de Sun, d'IBM, et de Apple pour ne citer que les plus utilisées, ben je te mets au défi de faire une application un tant soit peu complexe qui tourne impeccable sur les 4 sans introduire de tests spécifiques (si je tourne sur le JVM Microsoft, alors faire ça, si je tourne sur celle de Sun, alors faire ça, etc...)

La JVM de Microsoft, je la compte pas car elle est antique(elle n'a pas dépassé le JAVA 1.1 il me semble), lente et avec des incompatibilités introduites volontairement par Microsoft.
Pour la machine IBM, je n'ai pas eu a bosser avec mais aucun de mes collèges n'à jamais eu de problème d'incompatibilité avec celle de Sun.
J'ai fait plusieurs applications qui marchent aussi bien sous les machines Sun (PC / Linux) que Mac.
Les seuls tests particulier que j'ai eu a faire c'était pour que mes applis graphiques s'intégrent mieux au système.

Je pense que vous ne parlez pas de la même chose là, spectras ne parle pas de la VM J2SE elle-même, mais de l'implémentation J2EE qui se situe par dessus.