Utilisation de flex/bison dans application graphique Windows (API)

Résolu
uaip Messages postés 1466 Date d'inscription mardi 20 février 2007 Statut Membre Dernière intervention 7 février 2011 - 16 juil. 2009 à 19:00
uaip Messages postés 1466 Date d'inscription mardi 20 février 2007 Statut Membre Dernière intervention 7 février 2011 - 18 juil. 2009 à 16:45
Bonjour à tous

Je résume tout depuis le début. J'ai découvert flex et bison sous Linux, j'ai commencé un projet de compilateur sous le terminal : j'écrivais mes fichiers .l (pour flex) et .y (pour bison), je génerais les fichiers sources correspondants, et ajoutés à un main.c, je compilais le tout et le programme final fonctionnait (le programme ne fait que parser un fichier de code, convertit en C, et appelle gcc pour compiler un exécutable final). J'ai "exporté" ce projet sous Windows et je l'ai continué. Sous console, tout se compile parfaitement et le programme se lance (pour gcc, j'ai utilisé minGW). Sous Windows, j'ai du ajouter la bibliothèque libfl.a (pour Codes::Blocks).
Or voilà, depuis que j'ai modifié mon main.c (projet sous console) en un projet win32 graphique, le code se compile, mais l'exécutable n'est pas lancé (code d'erreur directement).
Je me suis rendu compte que c'est en incluant la lib libfl.a que ce problème survient. Pourtant, j'ai récupéré cette bibliothèque sur le site http://flex.sourceforge.net/ donc elle devrait être plus ou moins "officielle".
Je n'ai trouvé aucune réponse sur le net, ni d'autres exemples "concrets" de projets flex/bison win32.
Merci d'avance...


Cordialement, uaip.

3 réponses

uaip Messages postés 1466 Date d'inscription mardi 20 février 2007 Statut Membre Dernière intervention 7 février 2011
18 juil. 2009 à 16:45
Re-bonjour,
J'annonce pour les éventuels internautes qui tomberaient sur ce topic que j'ai trouvé une solution plus ou moins "bricolée". Déjà, je tiens à me corriger : yyin fonctionne aussi pour bison, mais ça n'a pas résolu mon problème. Du coup, j'ai divisé mon programme en deux : une partie sous console (le compilateur) et une autre en GUI (l'interface du programme). En appuyant sur un bouton sur le GUI, ça appelle ShellExecute() qui lance le compilateur en donnant en 1er paramètre le hwnd de la fenêtre GUI (pour que le compilateur puisse envoyer des messages (erreurs, etc)). Ca a l'air de bien fonctionner pour le moment.
C'est vraiment pas top pour l'objectif que je m'étais fixé au départ, mais finalement, je me rends compte que Code::Blocks par exemple est foutu pareil (avec minGW). Donc je vais rester sur ça.

Merci Kotomine d'avoir pris la peine de me répondre.


Cordialement, uaip.
3
Kotomine Messages postés 112 Date d'inscription lundi 29 juin 2009 Statut Membre Dernière intervention 5 novembre 2009
17 juil. 2009 à 10:48
Si je me souviens bien, flex/bison lisent par défaut sur l'entrée standard, qui elle est fermée en mode graphique

Essaie de créer un fichier qui contient une grammaire à analyser, et de faire

yyin = fopen("monfich.txt","r"); avant ton yyparse()



(je suis peut-être dans le faux ..)



;I'm just keeping the hopeless cross to increase the meaninglessness
0
uaip Messages postés 1466 Date d'inscription mardi 20 février 2007 Statut Membre Dernière intervention 7 février 2011
17 juil. 2009 à 12:51
Salut,
Quand je disais que le programme ne faisait que parser un fichier de code, je voulais dire implicitement que l'entrée était redirigée. Je suis quand même conscient que ce n'était pas très clair.
En gros, j'ai ceci :
...
FILE *_FILE_=fopen("test","r");
if (_FILE_ == NULL)
{
        alert("Erreur d'ouverture des fichiers");
        return 1;
}
yyrestart(_FILE_); //Redirection de l'entrée standard
yyparse();
fclose(_FILE_);
...


(yyin doit fonctionner avec yacc, mais apparemment pas avec bison).
Mais je vais me pencher sur d'autres subtilités comme ça.

Cordialement, uaip.
0
Rejoignez-nous