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.

• BUILD_NOISY => 1 ensures that warnings and errors from the .XS/.c compile phase are also output to the terminal.

  Unfortunately it also produces a lot of clutter -- starting xxx/Finishing xxx -- that I'm not interested in, but getting the direct feedback of the C compiler output is more than compensation.

• NAME => '....' prevents the default of using the first 4 hex characters of the MD5 as a part of the build subdirectory name.

  This default is annoying because it means that if you've loaded the previous intermediate .c and .xs files into your editor, when you make a change and re-build, they become obsolete and you have to go off hunting to find out where their replacements are located.

  By explicitly naming them, when you've done a re-build, the same files get over written and you only need refresh to view the effects of the changes, My editor keeps track of changes to open files and can either notify you or automatically refresh them when you switch to the appropriate tab.

  This helps prevent one source of the "I edited the (wrong) file and nothing changed" gotcha.

• CLEAN_AFTER_BUILD => 0 prevents the I::C build process from throwing away the intermediate build files.

  Which is almost essential when debugging.

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.