Re: [gccsdk] Flex and Bison broken?

In message <dad7199954.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:

>
> Part of Bison source, there is examples, but any useage will show the problems.
> Though the error is not explicit, I believe the issue is with subpipe/exec arrangement not getting the environment or arguments to m4 properly, and I dont think it gets anything sensible back from m4 either.
>
> My approach to this problem is to merge the gnu m4 source into the gnu bison source, changing names in a few cases (symtab.c to m4symtab.c, output.c to m4output.c) and I'm hoping by renaming the m4 main( to m4main( that I can change the use of exec m4 to an internal function.
> The two sources are very similar, there is one conflict with rpl_malloc, but it is not needed by the m4 side once the original configuration is done.
> So I remarked it out of the combined config.h
> Reconfiguring would be a problem.
>
> I have the combined binary/libs building OK, it just needs the work done to call the m4main function through the subpipe/fork arrangement. It will be down to wether fork or vfork can meet the demand I think.
>
> I dont mind being made to look foolish if you can get bison/m4 to work the normal way though (-:
>

I only got so far with merging m4 and bison, but was better equipped to try a more conventional fork/exec from bison to m4.
Before, bison was chaining chunks of data to the stdin of m4 with subpipe.c
Now I've sidelined subpipe.c and Bison chains the chunks to a temp file.
Then bison fork/execs the same arguments to m4 except for the temp file replacing "-" and with extra argments "> /tmp/m4out"
The /tmp/m4out is then opened by bison to finally output the xxx.tab.c and xxx.tab.h
An aside, I found using "m4" instead of m4 allowed the exec to use the system path. Plain m4 expands to the M4 system variable, or the configured path.


I had a problem with bison losing the CWD with the complex filename example0.tab.c (no such file/directory)
Reducing the name to example0 or example0.c by using the -o option, and no problem.

I have added "@/" to the output name when dir_prefix is "" and this appears to have fixed the problem without breaking an -o (alternative output) that isn't the CWD.

A bit more fine tuning to do, such as unique /tmp/names and deleting them afterwards, but so far so good.
Alan, I can send you what I've done if you are interested, with a view to putting patches in the autobuilder.

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