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

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

#include "bar.h"

int bar (int in) {
  return in;
}
[download]

#include "baz.h"

int baz (int in) {
  return in + 1;
}
[download]

bar: 42
baz: 43
[download]

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

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

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.