> We're almost certainly going to need some kluges of that sort, so as
> long as they're not all over the place I won't object.
>
> But ... I've seen no evidence that those specific examples are needed.
> Why wouldn't we copy all the backend rules? And based on Michael's last
> comment it's unclear that we need to avoid adding spaces in the
> mechanically generated actions, either (which squares with my gut
> feeling about SQL syntax). You'll probably need to get into specific
> cases before finding out what kluges you need.
I think this was more an 'in principle' - if thats route is ok, then I'll
start hacking away properly...
I was thinking about the copy on/copy off for more the header info (before
the %%) - so we can have a really dumb script that just gets told what blocks
to copy - and what to ignore..
There will also be some grammer in the original which we'll need to replace
with some ecpg specifics - eg adding grammer for the variables etc.
Might be easier to just turn 'off' the original rules and have some custom
ecpg stuff appended to the generated code..
Theres also another thing that needs to be decided, which is if the generated
ecpg grammer should be developer generated (ie. Michael Meskes runs a script
and commits the output), or should be generated for each and every source
based installation. I personally would stongly favour the script being a tool
for ecpg tool developers and not used as part of a normal installation.
--
Mike Aubury
http://www.aubit.com/
Aubit Computing Ltd is registered in England and Wales, Number: 3112827
Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ
