Isukthar : oui, les redirections unix ( < | > ) ça ne marchera pas sous windows.
Je viens de voir le lien en question (que j'avais complètement zapé). J'essaie de transcrire la chose en un Makefile portable.

Correction, le > marche bien sous Windows.

J'ai pas vu l'intérêt des "| grep" donc j'ai enlevé ça. Après, changer les < en < et les > en > semble suffire pour avoir un Makefile compatible Windows.

Essaie http://pastebin.com/m15cdc1d7 .

Pour info, voici à quoi ressemble un des mes Makefile caml :
http://pastebin.org/15515
C'est quand même plus humain. Par contre il faut changer les variables entre les lignes 10 et 20 pour adapter à chaque projet.

----

Pour en revenir à ton message d'erreur :
« ocamlopt -o main.opt -inline 10 -unsafe -noassert -w Ae -I /usr/local/lib/ocaml/
3.11.0 -ccopt -L/usr/local/lib/ocaml/3.11.0 -cc cc main.cmx »
Moi je rajouterai un "graphic.cmxa" juste avant le main.cmx. Ce "graphic.cmxa" irait à la ligne 29 (LIBS_OPT = graphics.cmxa) dans mon Makefile.

Oui, les &gt je m'en suis aperçu tout à l'heure, c'est un bogue de viewvc. Il suffit de sortir le fichier via svn pour qu'il soit correcte. Je me sert de $(GREP) pour filtrer les fichiers produit automatiquement (c'est l'un des points que je veut changer car le fichier mli produit n'a pas un format adapté à grep).

Pour l'erreur sur le chemin d'accès, il faut l'ignorer (les options par défaut sont pour Linux et ce n'est qu'un warning), ou alors il faut modifier la variable LIBINSTDIR. À ce détail là le Makefile est probablement portable pourvu qu'on est les outils nécessaire (et de ce point de vue cat n'est pas plus étranger à windows que make lui même).

Pour graphics, il faut rajouter dans le makefile l'option
LIBS = graphics

Il faut bien comprendre que ce makefile n'est pas censé être copié dans chaque projet, mais juste inclue dans un petit makefile qui ressemble alors à ça :

LIBS=graphics
include OCaml.mk

Qui est suffisant pour un programme constitué d'un seul fichier.
À long terme, mon makefile est plus polyvalent (il permet, entre autre options importantes, de créer des bibliothèques). Mais il est peut-être plus complexe (quoi qu'on puisse difficilement faire plus simple pour ce genre de chose. Si tu l'utilise, n'hésite pas à poser ici les éventuelles questions que tu peut avoir dessus.

chris, je ne sais pas pourquoi tu qualifie cygwin d'abomination suprême, c'est relativement léger et ça fonctionne bien. De plus ça permet d'éviter les erreurs rencontrés par Isukthar. Il aura besoin d'autre outils à un moment ou à un autre et plutôt que de les installer un à un cygwin gère tout d'un coup.

Ce que je voulais dire pour le PATH qui est différent sous windows, c'est que, comme tu l'as expliqué, tu est obligé de le modifier à la main (et l'option est assez profondément enfouie) pour chaque programme que tu veux voir s'y trouver. Il n'y a l'équivalent de /usr/bin, sauf à mettre ses exécutable dans C:\windows ...

« Je me sert de $(GREP) pour filtrer les fichiers produit automatiquement (c'est l'un des points que je veut changer car le fichier mli produit n'a pas un format adapté à grep). » oui, ça d'accord. Mais pourquoi diable filtres-tu ? C'est ça que je n'ai pas compris.
Enfin ça n'a que peu d'importance, après tout, dans la vraie vie, les fichiers .mli qui ont de l'importance existent, donc pas besoin d'appeller la règle .ml .mli.

« Ce que je voulais dire pour le PATH qui est différent sous windows, c'est que, comme tu l'as expliqué, tu est obligé de le modifier à la main (et l'option est assez profondément enfouie) pour chaque programme que tu veux voir s'y trouver. Il n'y a l'équivalent de /usr/bin, sauf à mettre ses exécutable dans C:\windows ... »
tu peux toujours créer un tel répertoire et y déplacer les différents exécutables. Après ça donnera un beau bordel où on ne trouve rien comme sous Linux.
Une solution un peu plus sexy serait de pouvoir mettre C:\Program Files\*\bin dans le Path. Faudrait que je creuse pour voir si Windows permet ça.
Enfin, tu peux toujours faire un :
$ set Path=%Path%:<insert_here_a_repertory>
$ <command>
si tu veux un changement ponctuel (enfin il faut se reloguer pour qu'il disparaisse). Cette variante là n'est pas très compliquée, elle.

J'oubliais, cygwin c'est une solution dégueulasse parce quand on développe sous Windows pour Windows, on n'utilise pas un faux Unix (relativement cagneux en plus) pour le faire.

J'ai séparé le makefile et le OCaml.mk et j'ai mis LIBS = graphics dans le makefile. Maintenant j'ai ça comme erreur:

ocamlopt -o main.opt -inline 10 -unsafe -noassert -w Ae -I /usr/local/lib/ocaml/
3.11.0 graphics.cmxa -ccopt -L/usr/local/lib/ocaml/3.11.0 -cc cc main.cmx
'cc' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
File "caml_startup", line 1, characters 0-1:
Error: Error during linking
make: *** [main.opt] Error 2

Je te conseille d'utiliser ocamlc pour l'instant. Pour utiliser ocamlopt il faut installer un compilateur C en plus (et la version de ocaml qui va avec).

Gcc est fournit par MinGW. Donc soit tu changes le cc en gcc dans le Makefile, soit tu copies gcc.exe en cc.exe dans le répertoire bin de MinGW.

J'ai créé une copie de gcc apellée cc. Maintenant j'obtiens des référence indéfinies vers flexdll_dlopen, flexdll_...

Euh, là j'ai besoin du message d'erreur complet.

Tu utilises ocamllex quelque part ?

non, mais c'est une erreur connu de mingw utilisé avec ocaml (flex est le loader dynamique de ocaml, rien à voir avec lex, sauf le nom).

Est-ce que tu as bien installé la version de OCaml pour mingw si c'est le compilateur que tu utilise maintenant ?

J'ai bien la version MinGW, j'ai même réinstallé OCaml et ça ne marche pas. Voici le message d'erreur:
C:\Program Files\Objective
Caml\lib\libasmrun.a(win32.o):win32.c:(.text+0x323
):
undefined reference to `flexdll_dlopen'
C:\Program Files\Objective
Caml\lib\libasmrun.a(win32.o):win32.c:(.text+0x33a
):
undefined reference to `flexdll_dump_exports'
C:\Program Files\Objective
Caml\lib\libasmrun.a(win32.o):win32.c:(.text+0x363
):
undefined reference to `flexdll_dlclose'
C:\Program Files\Objective
Caml\lib\libasmrun.a(win32.o):win32.c:(.text+0x37d
):
undefined reference to `flexdll_dlsym'
C:\Program Files\Objective
Caml\lib\libasmrun.a(win32.o):win32.c:(.text+0x399
):
undefined reference to `flexdll_dlopen'
C:\Program Files\Objective
Caml\lib\libasmrun.a(win32.o):win32.c:(.text+0x3a8
):
undefined reference to `flexdll_dlsym'
C:\Program Files\Objective
Caml\lib\libasmrun.a(win32.o):win32.c:(.text+0x3b5
):
undefined reference to `flexdll_dlerror'
collect2: ld returned 1 exit status
File "caml_startup", line 1, characters 0-1:
Error: Error during linking
make: *** [main.opt] Error 2

Si vous trouvez pas, ça fait rien, je changerais de langage. J'aurais plus vite fait de porter mon code caml que d'arriver à compiler.

utilise ocamlc et ça fonctionnera très bien. Ou utilise cygwin (en installant ocaml via son installer si tu n'a pas besoin d'une des toutes dernières versions) et ça marchera très bien aussi, ou utilise la version pour VC++ (en l'installant) et ça fonctionnera très bien.

Mais mingw est une abomination suprême avec plein de hack et je ne te recommande pas du tout de l'utiliser (vengeance !).

Par contre, en aucun cas n'abandonne OCaml, c'est de loin le meilleur langage que je connais.

C'est vrai que c'est un excellent langage. C'est le 1er langage que j'ai appris et celui que j'ai le plus utilisé durant mes études.
Mais je trouve qu'ils font pas trop d'efforts pour le rendre populaire. Rien qu'à voir tous les problèmes que je rencontre, ou le manque d'IDE et libs.

Pédagogiquement parlant, Ocaml est excellent en effet.

Isukthar : Utilise ocamlc va. Tu y perds un peu en perf, mais as-tu vraiment besoin de performance ? Sinon, les problèmes tu les rencontres avec presque tous les langages. La solution c'est d'utiliser linux. Installation d'un compilateur pour le langage de ton choix en trois clics, présence d'outils puissants et fonctionnels, applications mieux pensées et plus riches, … Franchement, pourquoi développer sur une autre plateforme ?
(ok, je prêche pour ma paroisse là. )

Pour l'ide, il me semble avoir déjà cité (g)vim. Non seulement c'est un excellent IDE, mais en plus c'est vrai quelque soit le langage de prog utilisé.

dnob700 : moi je préfère mingw (qui est sûrement très goret quand on le regarde de près) à cygwin (qui est sûrement tout aussi goret quand on le regarde de près). Je préfère avec juste un make.exe moisi que toute une couche d'émulation cagneuse. À la limite, le moins moisi pour développer sous windows, c'est presque de virtualiser un Linux (et je dis ça alors que je déteste la virtualisation).

"Utilise ocamlc va. Tu y perds un peu en perf, mais as-tu vraiment besoin de performance ? Sinon, les problèmes tu les rencontres avec presque tous les langages. La solution c'est d'utiliser linux. Installation d'un compilateur pour le langage de ton choix en trois clics, présence d'outils puissants et fonctionnels, applications mieux pensées et plus riches, … Franchement, pourquoi développer sur une autre plateforme ? "

En fait c'était pour un petit jeu d'awélé. Pendant mes étude j'ai développé une version en mode console en OCaml. Donc la je voulais reprendre mon code pour ajouter une interface graphique, l'optimiser, le multi-threader, améliorer l'heuristique ...
En cours, il n'y avait pas vraimment de problème puisqu'on on était sous Unix en ligne de commande, en byte coden et en plus on nous filait le make file. Mais si je veux distribuer mon programme, je peux pas faire l'impasse sur Windows.

Et pour ce qui est des autres langages et de windows, c'est loin d'être aussi galère. J'utilise parfois Visual studio pour du C++ ou C# et c'est bien agréable. Même pour des langages moins connu comme le D, ça marche nickel avec code blocks.

« un petit jeu […] module Graphics […] » ocamlc est amplement suffisant pour ça. Ceux qui veulent jouer à ton jeu n'ont qu'à installer caml.

Plus sérieusement :
1) je ne suis pas sûr que juste coller un bytecode issu d'ocamlopt sur une machine lambda suffise pour faire marcher le jeu sur une machine lambda. J'avoue ne pas trop savoir comment ocamlopt gère sa sauce (et encore moins sous Windows) mais tu risques d'avoir besoin de .dll ou équivalent.
2) Vu la consommation que demande ton projet, ocamlc est amplement suffisant (sauf si tu as codé un moteur 3D avec des effets d'ombres via du ray tracing ).

Pour le C/C++, c'est vrai que ça va à peu près. On est plus au temps de mes débuts au la compilation d'un code C avec Dev-C++ chiait à cause d'erreurs dans le stdio.h.
Mais pour des langages genre Haskell ou même Python et Perl, ça doit pas être beaucoup plus la joie que pour Ocaml sous Windows.

Tiens, tu as code::blocks ? Si j'ai bien compris, c'est plus ou moins un fork de Dev-C++, donc il devait te fournir le make.exe et compagnie. Si ça se trouve, il suffisait juste d'ajouter le répertoire bin de CB dans ton Path (et donc pas besoin d'installer MinGW).

"Vu la consommation que demande ton projet, ocamlc est amplement suffisant (sauf si tu as codé un moteur 3D avec des effets d'ombres via du ray tracing "

En mode console, le le choix de l'ordinateur n'est pas "instantané" au delà de la profondeur 6. Donc passer en code natif était un moyen facile et rapide d'améliorer ça.

Pour ce qui est de codeblocks, on peut télécharger une version avec ou sans MinGW. J'ai pris la version sans MinGW puisque j'ai déjà MinGW à côté. Mais au final, il faut quand même avoir MinGW (sauf si on passe par le compilateur de Microsoft ou autre).

« En mode console, le le choix de l'ordinateur n'est pas "instantané" au delà de la profondeur 6. » ça ne devrait pas changer en mode graphique. C'est si compliqué que ça l'awélé ? J'avais souvenir de règles plutôt simples, et d'un espace de possibilités pas spécialement grand.
Après, il faut voir ce que tu appelles "pas instantané" et les performances de la machine à la «profondeur 6». Si la machine met une seconde et qu'elle gagne presque à tous les coups contre de très bons joueurs, tu peux t'arrêter là. Il n'y a rien de plus frustrant que de se faire plier par la machine tout le temps, dédicace à l'othello…

Ha, Dev-C++ vient forcément avec "MinGW" lui. Je mets des " parce qu'on trouve dans son bin/ quelques exécutables que je soupçonne fort d'être ceux de MinGW, mais je n'ai jamais pris la peine de vérifier si c'était exactement ceux de MinGW, une version modifiée, un fork, ou complètement autre chose.
Bref, c'est sans doute mieux (moins chiant) de laisser code::blocks / Dev-C++ installer lui-même MinGW en fait.

dev c++, c'est pas le truc super plus maintenu depuis 10 ans ?