Re: automatic parser generation for ecpg

Mike Aubury <mike(dot)aubury(at)aubit(dot)com> writes:
> In reality - it doesn't look too disimilar from the awk original. I didn't
> appreciate that we'd probably need to keep 2 versions (one for unix and one
> for windows). In that case - I'd argue that we only need to "maintain" one
> and regenerate the other when required. Provided they both work the same, I'd
> say it doesn't matter what the perl one looked like, because thats not the
> one that'd be maintained :-)

That'd only be acceptable if the code conversion were fully automatic
--- given your reference to "tweaks" I wasn't sure if that could be the
case.

> Personally - I'd be tempted to keep this as a background process for
> the ecpg maintiner anyway rather than a normal end user.

While we could approach it that way, it doesn't really meet all the
goals I was hoping for. The current process is unsatisfactory for at
least two reasons above and beyond "Michael has to do a lot of
gruntwork":

* People hacking on the core grammar might break ecpg without realizing
it. They need short-term feedback from the standard build process,
or at the worst from the standard buildfarm checks.

* For the last little while, changing the core keyword set breaks ecpg
completely, which means we have the worst of all possible worlds: core
modifiers have to hack ecpg to get it to compile, and then Michael has
to do more work to get it to actually work right.

I've been willing to put up with the second problem because I expected
the ecpg grammar build process to become fully automatic soon. If that
doesn't happen then I'm going to be lobbying to revert the change that
made ecpg depend directly on the core keyword set.

regards, tom lane