Re: [svn:parrot] r13343 - trunk/compilers/imcc
Allison Randal
>
> * However, the bison interface does not support both "interp"
> and "yyscanner" as flex inputs; so I created a patch file
> at compiler/imcc/imcparser.c.diff -- it needs to be applied
> manually whenever imcc.y is regenerated into imcparser.c.
>
> This is really suboptimal, and should be folded into the
> build system. But then again, $(YACC) and $(LEX) are both
> at this moment hard-coded to "echo" and not governed by the
> normal "make" rules anyway, so I'm not sure how best to address
> this build problem. Suggestions welcome.
This is not a maintainable build solution. Revert and come back when you
have one.
(It's always okay to say "I've gotten this far in implementation but hit
a snag". Just don't commit until you resolve the snag.)
Allison
Joshua Hoblitt
FYI, $(YACC) and $(LEX) are set to useful values when "--maintainer" is
passed to Configure.pl. If apply a patch as part of the build processes
is really the only option then a conditional could be added to root.in
to only apply the patch when --maintainer is in effect.
-J
--
Audrey Tang
在 2006/7/18 上午 4:38 時，Allison Randal 寫到：
> aud...@cvs.perl.org wrote:
> This is not a maintainable build solution. Revert and come back
> when you have one.
Reverted.
Audrey
Audrey Tang
在 2006/7/18 上午 4:38 時，Allison Randal 寫到：
> 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?
If the latter, an extra line of Makefile rule suffices. If the
former, a bison post-processor wrapper is needed.
Thanks,
Audrey
Audrey Tang
在 2006/7/18 上午 5:24 時，Audrey Tang 寫到：
Assuming both were considered unmaintainable, fixed them, and
committed again as r13348.
I'd be willing to revert r13348 again if you find anything wrong with
it, but a more specific response would be appreciated.
Thanks,
Audrey
Audrey Tang
在 2006/7/18 上午 6:21 時，Audrey Tang 寫到：
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.
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 .
So, is this maintainer-side dependency (bison 2.2+, flex 2.5.33+;
does not affect the user) a reasonable cost for IMCC reentrancy?
Thanks,
Audrey
Allison Randal
>>>> 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