I hope I do not misunderstand your case, but I believe my experience with Image::DecodeQR::WeChat can help you (re: https://metacpan.org/pod/Image::DecodeQR::WeChat#IMPLEMENTATION-DETAILS). In that, I am linking against opencv library via a "normal" C program (C++ actually, but with C it is way simpler) wherein all my logic happens and calls to opencv's functions are placed. Then I create a very vanilla XS (you can copy-paste "mine" which already receives some input parameters and returns an arrayref of results back to perl code). Then place that intermediate C file in basedir of module. MM::EU will compile it. For distributing, just set the LIBS, CFLAGS, LDFLAGS in Makefile.PL to link to the compiled (DLL) C file and include that DLL somewhere in your distribution.

To recap: 0) forget Inline::C (though it is a *great* module). 1) create a vanilla XS file where you receive some params and return back results. That's documented and I climbed that learning curve ok-ish. In this XS, do not place any other program logic. Instead, 2) place all your program logic in a separate C file to be called via some functions. The benefit of this is that a) this C file will not be compiled along with Perl headers and all the problems usually occuring with macro-name clashes can be avoided, it is a perl-independent C file and b) in the C file, you are not constrained by XS idioms. 3) In XS just call the functions in your C file (and including appropriate C header file). A slight complication would be getting the XS function's (the one your Perl-code will call) input parameters and adjusting them for your C function calls. In my case I had to allocate memory and copy input parameters data into these and pass these to the C function, but that was my case. Also note that I arrived to above setup because including opencv function calls from within Inline::C or XS failed because opencv's headers contain macros and functions which clash with Perl's own name-sakes(!). If you don't have this constraint then your solution can be simpler. Bottomline is: vanilla XS with just a simple call to your C function which is implemented in its own C file in order to avoid any XS idioms and/or Perl header name clashes.

bw, bliako

In reply to Re: Better way to force Inline to use compiled binary instead of C source? by bliako
in thread Better way to force Inline to use compiled binary instead of C source? by vr

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • 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:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, 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, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.