Andy Dougherty wrote:

> ... make the barrier to running languages/perl6 as low as possible,


My concerns too.

(Some history)

- I sent all the patches to get P6C running with 5.005_03
- I'm currently 95% maintaining/pushing the per6 driver (perl6)
- last ~50 Kb imcc patches originated from my keyboard, next 80 in qu)


> which means making imcc build as portably as possible.


AOL


> By default, traditional yacc puts its output files in y.tab.[ch].  Thus
> my imcc/Makefile currently has
> 
>       $(YACC) -d -v imcc.y
>       mv y.tab.c imcparser.c
>       mv y.tab.h imcparser.h
> 
> That's no problem, 


.... if operating system? shell? can parse the token "mv" SCNR ;-)

> ... and works with YACC='yacc', 'bison -y', or 'byacc'.


Ack, is see no problem too use these funny y.tab files (I used these 
some ~15 years ago, where I had them in DOS, brrr)


> However, the intermediate filename 'y.tab.c' isn't necessarily portable,

> if I remember my Windows and VMS lore correctly.  However, those platforms
> probably have bison, which understands the simpler -o imcparser.c output
> option.


So the first question actually is, is there a platform, parrot will 
support, where there is/will be.. no bison.

And second, you did ask last time already: We don't need stack expansion 
or whatever fancy features, imcc - as already Melvin said - is parsing a 
simple language.

Where are your portability issues?


> Thus what I'd really like to do here is generate two different makefile
> fragments, depending on whether or not the user is using bison or (yacc or
> byacc). With the current substitution-driven makefile.in system, it's not
> obvious to me how best to do that.  Anyone have any suggestions?

I'm not totally convinced, to actually look at, what a user is using 
(bison vs yacc), but, what IMHO matters is, what tool is available + 
working on this platform. There could be some dependencies for 
installation + of course your proposed workarounds for incompatiblities)

I would disagree towards perl5 like solutions, that need patching the 
parser.c, because platform's yacc is borken) (But I don't know all the 
platforms in free wild ;-)

imcc does (and will) need e.g. Parrot_dlopen and _dlsym, to figure out, 
  which op might take which argument(s). This constraint is IMHO more 
critical (WRT building) then your concerns, which must all be solved too 
of course, yes.

leo

Reply via email to