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 Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C', NAME => 'scriptname', CLEAN_AFTER_BUILD =>
// XS code here
# perl code here
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.
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.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||