In message <dub120-w387dd353c097bcd506734ef0...@phx.gbl>
          alan buckley <alan_...@hotmail.com> wrote:

> WPB wrote on Date: Sat, 7 Feb 2015 20:27:31:
> > Guess what? I'm back!
> >
> > So, now with everyone's help (thank you), I've progressed to the point
> > that 'make' is trying to invoke flex and then bison.
> >
> > Both fail. Flex with the following error:
> >
> > File '$.usr.local.bin.m4' not found
> >
> > I know there is a port of 'm4' at riscos.info, but it's certainly not
> > going to be found at that location on my hard drive! From my limited
> > experience of Linux, that looks like a Linux path converted to a RISC OS
> > path. I get the same error when trying a very simple invocation of 'flex'
> > from the command line. Would people agree that 'flex' is broken, or am I
> > doing something wrong?
> >
> > So, I plugged in Rik Griffin's port of 'flex'
> > (http://homepage.ntlworld.com/rik.griffin/) and if I change the paths
> > appropriately (because it's a Norcroft-compiled version, so has no sfix
> > swapping implemented) I can get it to work.
> >
> > Then we get to Bison, which fails similarly:
> >
> > bison -t -v -b parser -d -o OBJECTS/parser.tab.c src/parser.y
> > src/parser.y:93.17-24: warning: symbol OPERATOR redeclared
> > src/parser.y:94.15-23: warning: symbol MACROTEXT redeclared
> > src/parser.y:263.1: warning: a ';' might be needed at the end of action
> > code
> > src/parser.y:263.1: future versions of Bison will not add the ';'
> > src/parser.y:275.1: warning: a ';' might be needed at the end of action
> > code
> > src/parser.y:275.1: future versions of Bison will not add the ';'
> > src/parser.y:522.1: warning: a ';' might be needed at the end of action
> > code
> > src/parser.y:522.1: future versions of Bison will not add the ';'
> > /HostFS::HostFS.$/AppsInUse/Dev/GCC474r1/!GCC/bin/bison:
> > /home/alanb/gccsdk/env/share/bison/m4sugar/m4sugar.m4: cannot open: No
> > such file or directory
> > make: *** [OBJECTS/parser.tab.c] Error 1
> >
> > So it looks like there's a hard-coded reference in there to a file:
> > /home/alanb/gccsdk/env/share/bison/m4sugar/m4sugar.m4 - again, it appears
> > 'bison' is broken. Would people agree?
> >
> > If anyone has any input on this, it would be greatly appreciated.
> >
>
> The path looks like it's from my machine when I last ran the autobuilder
> on bison. If anyone knows what the paths should be for RISC OS (or
> better still had a patch) I can look at fixing and rebuilding both flex
> and bison.
>
> Regards,
> Alan

I posted elsewhere that the BISON_PKGDATADIR and M4 environment variables can 
be used.
However I've found that though m4 will compile and work on it's own happily,
Bison has a complex subpipe system to use m4 as a filter.
Flex is failing for similar reasons I think.

The Berkely YACC compiles easily (and works), is available from Debian, and 
reportedly the best YACC available. There are a few 'tricks' that Bison can do, 
but wether these will be missed remains to be seen, Bison/M4 is very long 
winded compared to byacc which is self contained and only uses temp files. (no 
pipes, simpler source).

I found a variant of flex called reflex which seems to be similarly good so far.
The pair have worked with a Bison example, so they look promising.

I noticed Autoconf uses m4 so it would probably have complications also.

Ron M.









_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Reply via email to