http://www.perlmonks.org?node_id=933595


in reply to Exploring Inline::C (Generating primes)

It took a little time getting used to debugging under Inline::C.... However, you do have to take note that line numbers in error messages won't correspond with those in your Perl source code. Instead, they refer to a C source file that gets placed in the build directory, with an .xs suffix. Again, the error log and screen messages point to that same file.

This may or may not suit your preferences, but I always start my Inline::C files with:

#! perl -slw
use strict;
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C',  NAME => 'scriptname', CLEAN_AFTER_BUILD =>
+ 0;

// XS code here
...

END_C

# perl code here
...

[download]

This has several effects I find extremely useful.

But the main advantage of using this sequence of exactly 4 lines, is it means that the line numbers produced by the C compiler in its error messages logged to the screen, match exactly with those within the original I::C perl source file. Which means that most of the time there is no need to load the .c/.XS files in order to track down where the errors are, and so avoids another source of the "I edited the (wrong) file and nothing changed" gotcha.

And that is priceless.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Exploring Inline::C (Generating primes)
by MidLifeXis (Monsignor) on Oct 25, 2011 at 12:45 UTC

    It has been a while since I have coded anything extensive (for some definition of extensive) in C, but I seemed to remember being able to tweak the line number and file name reported by the compiler by using #line... directives. A little searching indicates that my memory was correct.

    Not having used Inline::C to this point, this question is being asked from an ignorant position: is Inline::C able to use the #line directive?

    --MidLifeXis

[reply]
[d/l]
[select]
      is Inline::C able to use the #line directive?

      Theoretically yes. But ...

      The XS pre-compiler already uses (something like) this to try and make error messages produce by the C compiler relate to line numbers in the .XS file.

      Inline::C extracts the source code from the .pl file, places it into an .XS file with some requisite pre- and post-amble, and then pre-compiles that to produce the the .c file. That then gets compiled to build a .dll/.so binary that is then dynamically linked back to the perl binary at runtime.

      I don't think anyone has tried to apply two levels of line control simultaneously. I'm not sure we humans would understand the results :)

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        I think the best way to enable Inline::C using #line directives would be to implement an xsubpp (== ExtUtils::ParseXS) option to NOT generate #line directives. That shouldn't be hard.

        ...

        Oops! Turns out that's already done! Check out the linenumbers option. I haven't tested it, though.

        This being said, I believe Inline::C is a deployment nightmare and should be avoided outside experiments accordingly.

        Once you learned the C and perlapi stuff to write Inline::C, XS is child's play.

[reply]

In Section Meditations