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