in reply to Re^2: External (extra) files when using Inline::CPP
in thread External (extra) files when using Inline::CPP

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.


Replies are listed 'Best First'.
Re^4: External (extra) files when using Inline::CPP
by swl (Parson) on Apr 17, 2024 at 04:11 UTC
      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 and 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 is executed.

      The rough hack I used:
      In Inline/ locate and replace
      croak "'$key' is not a valid config option for $class\n";
      croak "'$key' is not a valid config option for $class\n" unless $key eq 'OBJECT';
      In Inline/ apply this patch:
      --- CPP.pm_orig 2019-04-20 00:50:28.000000000 +1000 +++ 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 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, 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 - 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.

Re^4: External (extra) files when using Inline::CPP
by cavac (Parson) on Apr 18, 2024 at 06:00 UTC

    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.

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP