Audrey Tang wrote:
This is not a maintainable build solution. Revert and come back when
you have one.
Please clarify: What, exactly, is not maintainable? The presence of
a .diff file, or the fact that it needs to be applied manually?
Both.
Assuming both were considered unmaintainable, fixed them, and
committed again as r13348.
Excellent! :)
The obvious wrong thing with it is that it doesn't come with a check for
flex >= 2.5.33. Joshua on #parrot said he'll fix that in the morning.
Also good. Please add a check for the bison version too.
Another obvious point was the resilience of the post processor against
bison outputs. Fortunately, it appears that with bison >= 2.2, multiple
%lex-param is supported (though they need to be declared in separate
lines, unlike %parse-param), and multiple %parse-param is also made
available to all functions including the destructor. Hence if we can
bump the version dependency of bison too, then this can work without
source-level patching at all (committed as .
Agreed, I prefer this to a post-processor on the bison output.
So, is this maintainer-side dependency (bison 2.2+, flex 2.5.33+; does
not affect the user) a reasonable cost for IMCC reentrancy?
Yes. Periodically upgrading the tools we use is a good idea anyway.
Allison
