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

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');
[download]

And instead of providing the OBJECT config option as OBJECT => '$(O_FILES)', we now have to do something like:

OBJECT => ['./bar', './baz'],
[download]

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);
[download]

And that works fine straight away.
Thoughts ?

Cheers,
Rob

Comment on Re^4: Better way to force Inline to use compiled binary instead of C source? Select or Download Code

Replies are listed 'Best First'.
Re^5: Better way to force Inline to use compiled binary instead of C source? by bliako (Abbot) on Jun 28, 2022 at 13:48 UTC
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	[reply]
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);` [download] in the script. In checking up on these things, I changed baz.h to: `#define NVSIZE 100 int baz (int);` [download] and baz.c to: `#include "baz.h" int baz (int in) { return in + NVSIZE; }` [download] (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);` [download] which, after compiling cleanly, output: `bar: 42 baz: 142 NVSIZE: 8` [download] 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]