Hmmm, yes and no. Because I did not find a straight forward way to tell Inline::C NOT to cleanup XS code after successful compilation. From its source code, the cleanup option is in {API} hash which I do not know how to affect. The very round-about way of doing this was to break the compilation by introducing an obvious error in the C code. That would leave the XS file in the build dir. Albeit broken but easily fixable. That's all based on my own experiments as documentation is a bit scarce. It would be a good feature to allow for converting the hidden XS distribution to a stand-alone module in a straight-forward way. (Edit: see Anonymous response below with proper solution)

On the very serious other hand, NERDVANA mentions Inline::Module (unknown to me a minute ago) which provides exactly this functionality. I have not tried it yet.

FWIW, this tells Inline::C to place the output binaries to specific directory ("unhiding" it!) - provided output dir exists. BUT I did not manage to tell it to NOT cleanup so that I can use the XS code. So I can only use the binaries. (Edit: same as above edit)

use Inline C =>          
        Config =>
                # dir must already exist!
                DIRECTORY => 'xxx'
;
use Inline 'C';
# perl code
...
__END__
__C__
// C code
[download]

bw, bliako

An example XS: returning a 64-bit unsigned int? soso

great! thanks for CLEAN_AFTER_BUILD (Edit: so fortunate that BrowserUK did not delete that node!)