#line directives from PMC file should now work
Nicholas Clark
#line directives in the C source files it generates. This means that C errors
in PMC files under development will be reported by the C compiler as being at
the correct line in the source PMC file, rather than the pseudo-random line
in the auto-generated C file. This should help anyone writing PMCs
Builds pass with the --no-lines option in Makefile removed. Should this
be removed from the template Makefile so that all builds now use #line
directives?
Nicholas Clark
Leopold Toetsch
> I believe that I've now fixed all the bugs and made pmc2c2.pl emit accurate
> #line directives in the C source files it generates.
Great, thanks a lot.
> Builds pass with the --no-lines option in Makefile removed. Should this
> be removed from the template Makefile so that all builds now use #line
> directives?
Yep. Is there still that %ENV var around to turn line numbers off? - Or
was that in ops2c.pl - PARROT_NO_LINE is it, could be handy sometimes.
> Nicholas Clark
leo
Jeff Clites
> Nicholas Clark <ni...@ccl4.org> wrote:
>
>> Builds pass with the --no-lines option in Makefile removed. Should
>> this
>> be removed from the template Makefile so that all builds now use #line
>> directives?
>
> Yep. Is there still that %ENV var around to turn line numbers off? - Or
> was that in ops2c.pl - PARROT_NO_LINE is it, could be handy sometimes.
I'd really like a way to turn them off easily (for the ops as well,
actually). I find them to be counterproductive (for our stuff), since
what gets shown in the debugger isn't stuff you can actually get gdb to
evaluate.
JEff
Leopold Toetsch
> I'd really like a way to turn them off easily (for the ops as well,
> actually). I find them to be counterproductive (for our stuff), since
> what gets shown in the debugger isn't stuff you can actually get gdb to
> evaluate.
It depends. While hacking PMC files its much more useful to have the gcc
error line within the pmc files. Debugging ops is sometimes more
intuitive, if you see the corresponding .c file in the debugger, but not
always.
Anyway, as $ENV{PARROT_NO_LINE} is already in ops2c.pl, it should be
present in all build tools.
> JEff
leo
Jeff Clites
> Jeff Clites <jcl...@mac.com> wrote:
>
>> I'd really like a way to turn them off easily (for the ops as well,
>> actually). I find them to be counterproductive (for our stuff), since
>> what gets shown in the debugger isn't stuff you can actually get gdb
>> to
>> evaluate.
>
> It depends. While hacking PMC files its much more useful to have the
> gcc
> error line within the pmc files. Debugging ops is sometimes more
> intuitive, if you see the corresponding .c file in the debugger, but
> not
> always.
Sure--definitely depends on what you're doing. For me, I'm often
debugging a JIT problem, and when I end up in a normal-op call I need
to be able to examine the environment (registers, subsequent ops).
> Anyway, as $ENV{PARROT_NO_LINE} is already in ops2c.pl, it should be
> present in all build tools.
Or maybe also CLI options to the tools, so at least you can hand-modify
the Makefile to easily turn off some, and leave on other. Having a
Configure.pl parameter is also more consistent with everything else we
do, compared to an env. variable.
JEff