flex/bison et dev-c++

Bonjour à tous,

Je suis en train de porter une appli de Linux vers Windows XP (eh oui).

J'ai opté pour l'IDE Dev-C++, avec donc minGW derrière. Le problème est que j'ai des fichiers .l et .y à compiler, et que Dev-C++ ne gère que le C/C++ si je ne trompe pas (dites-moi que je me trompe, ça me ferait plaisir !!).

Je suis donc obligé de compiler ces fichiers avec flex et bison (qui - soit dit en passant - ne m'affichent jamais de messages d'erreurs ni de warnings à la compil j'ai l'impression) en ligne de commande (j'ai pas encore essayé de faire un script, quel langage me conseilleriez-vous d'ailleurs ?).

Quand j'ajoute les fichiers parser.tab.c et parser.tab.h générés (je n'inclue pas le lexer.c si je ne trompe pas) dans la liste des fichiers du projet dans Dev-C++, j'ai droit à une myriade d'erreurs "syntax error before numeric constant" devant toutes les lignes du type "typedef WINBOOL BOOL;" au moment de la compilation.

Je me doute que les fichiers que j'ai générés avec flex et bison ne doivent pas être conformes, j'ai pourtant fait :
flex -o lexer.c lexer.l
bison -d parser.y
dans un shell windows.

Je précise que j'ai dû ajouter flex et bison à la main car le minGW de Dev-C++ était vraiment trop minimaliste ! ;)

Voilà, je pense que j'ai mis à peu près toutes les infos nécessaires, précisez-moi s'il en manque ou si la forme n'est pas correcte pour ce post !
Toute aide ou remarque constructive est bien sûr la bienvenue,
Merci.

Olivier

Humm ... petite précision : je n'avais pas remarqué mais les fichiers dans lequels se trouvent les erreurs de synatxe ne sont ni le parser ni le lexer mais "windef.h", "wincon.h", "winbase.h", "wingdi.h" ... et j'en passe.
Ces fichiers sont apparemment inclus lors de la compilation avec bison.
Une aide please ...

Le windef.h n'est vraiment pas là pour me rassurer :

...
/* FIXME: This will make some code compile. The programs will most
likely crash when an exception is raised, but at least they will
compile. */
#if defined (__GNUC__) && defined (__SEH_NOOP)
#define __try
#define __except(x) if (0) /* don't execute handler */
#define __finally

#define _try __try
#define _except __except
#define _finally __finally
#endif

typedef unsigned long DWORD;
typedef int WINBOOL,*PWINBOOL,*LPWINBOOL;
/* FIXME: Is there a good solution to this? */
#ifndef XFree86Server
#ifndef __OBJC__
typedef WINBOOL BOOL;
...

Ce que je préfère dans l'histoire c'est le FIXME. L'intruction qui plante à la compilation est - je le rappelle - la dernière ligne que vous voyez : "typedef WINBOOL BOOL;", je ne vois d'ailleurs pas trop pourquoi !

Help ...

Bon. J'ai fini par trouver !
Il s'agit en fait d'un problème de redéfinition de MACROs dans les fichiers de Windows windef.h, winbase.h et tous ceux cités au-dessus.
Je viens de voir ta réponse jpthomasset, ça confirme effectivement ce que tu dis, merci !
C'est la ligne "typedef WINBOOL BOOL" qui m'empêche justement d'utiliser dans mes fichiers lex et yacc le token BOOL (et FLOAT aussi, j'ai eu la même erreur). En le remplaçant par MY_BOOL ça passe très bien.

A+ et merci pour la réponse !

P.S. En fait je porte un générateur de traffic DHCP/RADIUS (avec notions d'états) que j'ai développé en stage, sous Debian puis Mandrake.