I think that Inline::C already nicely handles the cases where additional C code has been compiled into object files or a library.
This is aimed at accommodating additional C code without having to do any pre-compiling.
This is pretty common in XS modules. I've done it myself in Math::Ryu, and you'll find it in ScalarList::Utils - to name just one of many other examples.
One unnecessary thing I've done in my demo script, is to #include the 2 headers ('bar.h' and 'baz.h').
In general, one might want to avoid doing that because those headers might define something that clobbers perl.
Removing the inclusion of those headers from the script still allows the script to work just fine, though "implicit declaration of function" warnings are emitted at compile-time for both bar and baz. Those warnings can be silenced by declaring:
extern int bar (int);
extern int baz (int);
in the script.
In checking up on these things, I changed baz.h to:
#define NVSIZE 100
int baz (int);
and baz.c to:
#include "baz.h"
int baz (int in) {
return in + NVSIZE;
}
(That was just to check that my perl's NVSIZE, which is defined to 8, did not get clobbered.)
The demo became:
use warnings;
use Inline C => Config =>
BUILD_NOISY => 1,
OBJECT => ['bar', 'baz'],
;
use Inline C =><<'EOC';
extern int bar (int);
extern int baz (int);
void foo(int i) {
printf("bar: %d\n", bar(i));
printf("baz: %d\n", baz(i));
printf("NVSIZE: %d\n", NVSIZE);
}
EOC
foo(42);
which, after compiling cleanly, output:
bar: 42
baz: 142
NVSIZE: 8
I might one day tidy the C.pm patch up a bit, create a test case, and file a PR with Inline::C.
At the moment, I'm not sure if I'm overlooking something significant.
(As previously mentioned, with the present patch, the '.h' and '.c' files need to be in the cwd. I've decided that I would prefer to keep it that way.)
Thanks bliako - always good to get some feedback from you !
Cheers, Rob | [reply] [d/l] [select] |