Re^2: External (extra) files when using Inline::CPP

[cavac]

Perfect, thank you!

I ended up with doing some extra magic in BEGIN, to automate those compile steps (.cpp and .h files in same directory):

#!/usr/bin/env perl

use v5.38;
use strict;
use warnings;

use Carp;
use Cwd;
use Array::Contains;

my $dir;
my $verbose;
BEGIN {
    $dir = getcwd;
    print "Working directory: $dir\n";

    $verbose = 0;
    if(contains('-v', \@ARGV)) {
        $verbose = 1;
    }
    
    # ---- Poor mans Makefile ---
    if(contains('--clean', \@ARGV)) {
        print "Cleaning up\n";
        my $cmd = 'rm -rf _Inline xkcd.o libxkcd.a';
        print "$cmd\n" if($verbose);
        `$cmd`;
        exit(0);
    }

    print "Compiling library...\n";
    foreach my $cmd ('g++ -c xkcd.cpp', 'ar -rc libxkcd.a xkcd.o') {
        print "$cmd\n" if $verbose;
        `$cmd`;
    }
    # ---- Poor mans Makefile ---

};

use Inline 'CPP';
use Inline CPP => Config =>
  BUILD_NOISY => $verbose,
  INC => '-I' . $dir,
  LIBS => '-L' . $dir . ' -lxkcd',
;
 
for(1..3) {
    print "XKCD Dice roll: ", cast_die(), "\n";
}
 
__END__
__CPP__

#include "xkcd.h"
 
int cast_die() {
    int rolled = xkcd_dice_roll();
    return rolled;
}

Hmm, i also tested without the empty lines at the bottom of the files and it worked fine. But i dimly remember having the same (or similar) issue to yours on another project.

[syphilis]

I ended up with doing some extra magic in BEGIN, to automate those compile steps

AIUI, if you were to instead turn the project into a module (with Makefile.PL and XS file, etc.) you wouldn't need to create a library, nor would you even need to precompile the .cpp file.
That can all be taken care of automatically by the Makefile.PL, courtesy of the OBJECT=>'$(O_FILES)' option being passed to WriteMakefile() .

However, AFAIK, that capability has not been ported to the Inline::C and Inline::CPP build procedures.
I'm not sure why that has not yet been attended to. Maybe it's difficult, or maybe it's just that no-one has got around to doing it.

Cheers,
Rob

[swl]

Maybe it's a capability within Inline::Module?

[syphilis]

Maybe it's a capability within Inline::Module?

Quite likely, assuming that it's using Inline solely for the generation of the XS file, and not the generation of the Makefile.PL.
For generation of XS files I use InlineX::C2XS/InlineX::CPP2XS - both of which also have the capability of generating a Makefile.PL with the OBJECT=>'$(O_FILES)' argument to WriteMakefile()).

The problem with Inline::C and Inline::CPP is that, for the OBJECT=>'$(O_FILES)' approach to work, the .c or .cpp file(s) (xkcd.cpp, in this case) needs to be in the build directory.
However, one doesn't know in advance the location of the directory in which the build will actually take place.

There's only a couple of simple hacks to C.pm and CPP.pm needed to enable the passing of the the OBJECT=>'$(O_FILES)' argument to the Makefile.PL that Inline generates in the build directory.
And I've found that those rough hacks work fine so long as xkcd.cpp and xkcd.h have been placed in the build directory before test.pl is executed.

The rough hack I used:
In Inline/C.pm locate and replace

croak "'$key' is not a valid config option for $class\n";

with:

croak "'$key' is not a valid config option for $class\n"
          unless $key eq 'OBJECT';

In Inline/CPP.pm apply this patch:

--- CPP.pm_orig 2019-04-20 00:50:28.000000000 +1000
+++ CPP.pm      2024-04-17 21:16:22.142182800 +1000
@@ -114,6 +114,9 @@
   while (@config_options) {
     my ($key, $value) = (shift @config_options, shift @config_options
+);
     $key = uc $key;
+    if ($key eq 'OBJECT') {
+      $o->{ILSM}{MAKEFILE}{OBJECT} = $value;
+    }
     if ($key eq 'NAMESPACE') {
       _handle_namespace_cfg_option($o, $value);
     }

I slightly alter test.pl to be:

use Inline CPP => Config =>
  BUILD_NOISY => 1
  CLEAN_AFTER_BUILD => 0,
  OBJECT => '$(O_FILES)',
;
    
use Inline CPP;

for(1..3) {
    print "Perfect random number: ", cast_die(), "\n";
}
 
__END__
__CPP__

#include "xkcd.h"
 
int cast_die() {
    int rolled=xkcd_dice_roll();
    return rolled;
}

Then I run perl test.pl, which fails because of an undefined reference to xkcd_dice_roll()
Then remove all files from the build directory (./_Inline/build/test_pl_b6be).
Then copy xkcd.h and xkcd.cpp to the build directory (./_Inline/build/test_pl_b6be).
Then re-run perl test.pl - which succeeds this time.
On inspecting the build directory (./_Inline/build/test_pl_b6be), I can see that xkcd.cpp has been compiled into xkcd.o, and there is no library.
I don't recommend doing it this way - it's more just a proof of concept that this approach could be made to work.

Cheers,
Rob

[cavac]

If i release something, then yes, i will use proper modules with a Makefile.PL. But i really wanted an easy way to run local tests and one-off tools that doesn't require going through the steps.

Inline is so much nicer for that can of stuff than using h2xs, because it does all the that for you on the fly, making it easier to experiment with interfaces and stuff.