Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^5: Better way to force Inline to use compiled binary instead of C source?

by bliako (Monsignor)
on Jun 28, 2022 at 13:48 UTC ( #11145149=note: print w/replies, xml ) Need Help??


in reply to Re^4: Better way to force Inline to use compiled binary instead of C source?
in thread Better way to force Inline to use compiled binary instead of C source?

syphilis++, perhaps compiling the bar/baz sources to objects ends up too complex? E.g. more than 1 source files, complicated compilation flags, 3rdparty dependencies, lex+yacc preprocessing.

How about user either provides objects already compiled (and you have coded that in above post). This is the case where author distributes objects-only. Or *author* provides a tarball/src-dir containing all the necessary files and workflows (e.g. a Makefile which a) provides a target such as 'objects-for-inline-C' and b) reads optional ENV-vars for CC and other flags that Inline::C wishes to inject into this sub-compilation) to compile the required objects. This case is for when preparing for the public distribution of objects-only version. It can be run via a subshell, before Inline::C starts its own compilations.

bw, bliako

  • Comment on Re^5: Better way to force Inline to use compiled binary instead of C source?

Replies are listed 'Best First'.
Re^6: Better way to force Inline to use compiled binary instead of C source?
by syphilis (Archbishop) on Jun 29, 2022 at 04:02 UTC
    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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11145149]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2022-10-05 00:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My preferred way to holiday/vacation is:











    Results (20 votes). Check out past polls.

    Notices?