Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

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

by bliako (Monsignor)
on Jun 15, 2022 at 12:34 UTC ( [id://11144769]=note: print w/replies, xml ) Need Help??


in reply to Better way to force Inline to use compiled binary instead of C source?

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

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

    Yes - that's fairly straightforward in the usual XS environment.
    Has the same capability not been ported to Inline::C ? (I certainly don't know how to do it in Inline::C, but I've never even wondered about it before.)
    I wondered whether Inline::C's "autowrap" feature might be useful here, but it seems geared towards accessing C libraries rather than C source code.

    Anyway ... is that the issue that has prompted this thread ?
    I couldn't really work out what the issue was, and I'm still not too sure.

    Cheers,
    Rob
      Has the same capability not been ported to Inline::C ?

      I've had a look ... and the capability in question has NOT been ported to Inline::C, but it seems do-able.
      Firstly, the patch to Inline/C.pm:
      --- C.pm_orig 2021-12-20 22:11:48 +1100 +++ C.pm 2022-06-27 19:27:27 +1000 @@ -177,6 +177,10 @@ $o->{ILSM}{XS}{PREFIX} = $value; next; } + if($key eq 'OBJECT') { + $o->add_string($o->{ILSM}{MAKEFILE}, $key, $value); + next; + } if ($key eq 'FILTERS') { next if $value eq '1' or $value eq '0'; # ignore ENABLE, +DISABLE $value = [$value] unless ref($value) eq 'ARRAY';
      And the Inline::C demo:
      use warnings; use Inline C => Config => BUILD_NOISY => 1, OBJECT => '$(O_FILES)', ; use Inline C =><<'EOC'; #include "bar.h" #include "baz.h" void foo(int i) { printf("bar: %d\n", bar(i)); printf("baz: %d\n", baz(i)); } EOC foo(42);
      bar.h prototypes the bar function:  int bar (int);
      baz.h prototpyes the baz function:  int baz (int);
      bar.c defines the bar() function:
      #include "bar.h" int bar (int in) { return in; }
      and baz.c defines the baz() function:
      #include "baz.h" int baz (int in) { return in + 1; }
      It's probably important that each of those 4 files terminate with at least one empty line.

      But there's a snag I haven't quite got around yet: The first time I run my Inline::C script, it fails to compile because of undefined references to 'bar' and 'baz'. I then manually copy bar.h, baz.h, bar.c and baz.c to the Inline build directory that was created by that first run ... then I re-run the script, and all goes fine. And I end up with the expected output of:
      bar: 42 baz: 43
      So ... I wonder if there's some way that I can make bar.h, baz.h, bar.c and baz.c visible to the build process without having to move them to the build directory ?
      Essentially, I think the problem is that, with the current OBJECT => '$(O_FILES)' arg, the .c snd .h files need to be in the same directory as the auto-generated Makefile.PL (ie the script's build directory).
      I'm hoping there's some way to get the message across that we want to use the .c and.h files from a different location.
      Otherwise, we face the task of getting Inline to move those files across to the build directory *before* the auto-generated Makefile.PL is run.

      Any ideas ? (I'll keep fiddling with it and see if I can come up with the right solution.)
      Having to manually copy files and re-run commands strikes me as being a little less than optimal ;-)

      Cheers,
      Rob
        So ... I wonder if there's some way that I can make bar.h, baz.h, bar.c and baz.c visible to the build process without having to move them to the build directory ?

        Not that I can see.
        So we're left with the option of having Inline automatically copy our '.h' and '.c' files to the required location.
        The required patch to C.pm changes to:
        --- C.pm_orig 2021-12-20 22:11:48 +1100 +++ C.pm 2022-06-28 22:08:10 +1000 @@ -177,6 +177,20 @@ $o->{ILSM}{XS}{PREFIX} = $value; next; } + if($key eq 'OBJECT') { + $o->mkpath($o->{API}{build_dir}) unless -d $o->{API}{buil +d_dir}; + require File::Copy; + $o->add_string($o->{ILSM}{MAKEFILE}, 'OBJECT', '$(O_FILES +)'); + die "'OBJECT' must specify an array reference" + unless ref($value) eq 'ARRAY'; + for my $fn(@$value) { + File::Copy::copy("${fn}.h", $o->{API}{build_dir} . "/${ +fn}.h") + if -e "${fn}.h"; + File::Copy::copy("${fn}.c", $o->{API}{build_dir} . "/${ +fn}.c") + if -e "${fn}.c"; + } + next; + } if ($key eq 'FILTERS') { next if $value eq '1' or $value eq '0'; # ignore ENABLE, +DISABLE $value = [$value] unless ref($value) eq 'ARRAY'; @@ -374,7 +388,7 @@ open $lockfh, '>', $file or die "lockfile $file: $!"; flock($lockfh, LOCK_EX) or die "flock: $!\n" if $^O !~ /^VMS| +riscos|VOS$/; } - $o->mkpath($o->{API}{build_dir}); + $o->mkpath($o->{API}{build_dir}) unless -d $o->{API}{build_dir}; $o->call('preprocess', 'Build Preprocess'); $o->call('parse', 'Build Parse'); $o->call('write_XS', 'Build Glue 1');
        And instead of providing the OBJECT config option as OBJECT => '$(O_FILES)', we now have to do something like:
        OBJECT => ['./bar', './baz'],
        That's assuming that the '.h' and '.c' files are in the cwd. Otherwise, modify accordingly. ... oops ... I'll modify the patch later to allow for files not being in the cwd. )
        The demo I provided earlier therefore becomes:
        use warnings; use Inline C => Config => BUILD_NOISY => 1, OBJECT => ['./bar', './baz'], ; use Inline C =><<'EOC'; #include "bar.h" #include "baz.h" void foo(int i) { printf("bar: %d\n", bar(i)); printf("baz: %d\n", baz(i)); } EOC foo(42);
        And that works fine straight away.
        Thoughts ?

        Cheers,
        Rob
      I wondered whether Inline::C's "autowrap" feature might be useful here

      thanks, this seems like the "Inline option" I was looking for: function declaration only in C embedded in Perl, and no need in wrapper *.pm. However, I didn't expect that to compile my real code (not trivial add) -- which itself links to a few libs -- to a dll would require such effort to "construct" the correct command line (to type it, at least), it's a bit out of my league, I'm feeling like monkey copying text fragments without understanding the basics. All the more reason to appreciate what Inline::C is doing transparently, I think I'll stay with "blib" solution outlined in OP. Thank you everyone for answers.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2024-03-29 01:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found