Newsgroup: it.comp.programmare.win32
Titolo: make flex e bison

Ho un problema con i sorgenti generati automaticamente da flex e
bison e del make file all'interno del quale vengono usati.
Qualcuno usa gli strumenti di sopra in ambiente Windows?
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 
Ciao, io non uso flex e bison (anzi se sai di qualche buon tutorial ;)), 
ma so che alcune implementazioni del make hanno dei problemi.
Che versione stai usando?
-- 
Se non conosci la netiquette o il quoting,
ti prego, prima di rispondere, leggi qui:
http://www.marco5x.net/usenet/galateo.php
http://www.marco5x.net/usenet/quoting.php

 Che versione stai usando?
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
Il problema e' che i file ".c" generati automaticamente da flex e
da bison non vengono trovati nella directory dove li spedisco e
non riesco a trovare un modo per scrivere una regola automatica che
compili tutto al primo colpo senza darmi errori di file non trovati.


 compili tutto al primo colpo senza darmi errori di file non trovati.
Non so se è relativo al tuo problema (sono molto parassita su queste 
cose) ma in un makefile del tree-source del postgresql ho trovato questo:
# scan is compiled as part of gram
gram.o: $(srcdir)/scan.c
# There is no correct way to write a rule that generates two files.
# Rules with two targets don't have that meaning, they are merely
# shorthand for two otherwise separate rules.  To be safe for parallel
# make, we must chain the dependencies like this.  The semicolon is
# important, otherwise make will choose the built-in rule for
# gram.y=>gram.c.
$(srcdir)/gram.c: $(srcdir)/parse.h ;
$(srcdir)/parse.h: gram.y
ifdef YACC
	$(YACC) -d $(YFLAGS) $<
	mv -f y.tab.c $(srcdir)/gram.c
	mv -f y.tab.h $(srcdir)/parse.h
else
	@$(missing) bison $< $@
endif
$(srcdir)/scan.c: scan.l
ifdef FLEX
	$(FLEX) $(FLEXFLAGS) -o'$@' $<
else
	@$(missing) flex $< $@
endif

 cose) ma in un makefile del tree-source del postgresql ho trovato questo:
Purtroppo non sembra risolvere il problema. Forse mi sono
imbattuto in una limitazione/caratteristica relativa a
make/ambiente di esecuzione.
Per adesso ho risolto dando il nome completo di path ai prerequisiti,
visto che gli obj del parser e dello scanner dipendono solo dai ".c"
(in realta' lo scanner dipende anche dal ".h" generato assieme al
parser, ma i prerequisiti diventavano lunghi una quaresima) la cosa
e' fattibile. :-)
parser.obj: C:/pathCompleto/parser.c
   $(CC) $(CFLAGS) $(MT_LIB) $(PRJ_INCLUDE) -Fo$(<D)/$(OBJs_DIR)/$@ $<
scanner.obj: C:/pathCompleto/scanner.c
   $(CC) $(CFLAGS) $(MT_LIB) $(PRJ_INCLUDE) -Fo$(<D)/$(OBJs_DIR)/$@ $<
Non e' che mi piaccia tanto... ma funziona.
In ogni caso, grazie dell'attenzione.
C:\>iao Angelo
P.S. Non sono proprio fesso e per accorciare la lunghezza dei
     prerequisiti ho provato anche
parser.obj: $(PARSER_DIR)/parser.c
   $(CC) $(CFLAGS) $(MT_LIB) $(PRJ_INCLUDE) -Fo$(<D)/$(OBJs_DIR)/$@ $<
con $(PARSER_DIR) definito nel make principale che include tutti gli
altri, ma proprio non ne vuole sapere di funzionare. :-)
ma proprio non ne vuole sapere.


 ma proprio non ne vuole sapere.
Posso domandarti come hai definito $(PARSER_DIR) ?
Ma sopratutto, stai usando MINGW32 con l'MSYS?
Il problema potrebbe essere come l'msys interpreta le cartelle.
Prova ad usare una sintassi come questa: /c/WORK/CPP/PGWIN32
M.

 Prova ad usare una sintassi come questa: /c/WORK/CPP/PGWIN32
Non cerdo che cl la digerirebbe.
C:\>iao Angelo
