Re: Need help using Inline::Module with JavaScript::Embedded

I want to compile the C library in JavaScript::Embedded at install time, not every time it is used.

Ok ... apply this patch (or make the specified changes by hand) to Embedded.pm.
Update: Patch corrected to remove errant whitespace. (Thanks LanX.)

--- Embedded.pm_orig    2022-07-14 21:12:05 +1000
+++ Embedded.pm    2022-07-14 12:01:26 +1000
@@ -4,6 +4,14 @@
 use Carp;
 use Data::Dumper;
 use Scalar::Util qw( weaken );
+
+use Config;
+BEGIN {
+  # Create Inline's build directory:
+  mkdir "$Config{installsitelib}/_Inline"
+    unless -d "$Config{installsitelib}/_Inline";
+};
+
 our $VERSION = '2.7.1';
 
 my $GlobalRef = {};
@@ -315,6 +323,9 @@
 }
 
 use Inline C => config =>
+    build_noisy => 1,
+    clean_after_build => 0,
+    directory => "$Config{installsitelib}/_Inline",
     typemaps => _get_path('typemap'),
     INC      => '-I' . _get_path('../C') . ' -I' .  _get_path('../C/l
+ib');
     # myextlib => $Duklib,
[download]

I've assumed that $Config{installsitelib} always exists, and is writable.
I think those are fairly safe assumptions.
The thing is that, in order to avoid the re-compilation issue, you need to assign a specific directory as Inline's build directory.

Setting of the "build_noisy" and unsetting of the "clean_after_build" config options is not really needed - they just make things a little clearer. (IMO, "build_noisy" should be set by default.)
Unsetting the "clean_after_build" option allows us to go into the build directory and view the XS and C files that Inline::C generated. Otherwise, those files are deleted when the build has been completed.

If, having built the module, you go into the $Config{installsitelib}/_Inline/build/JavaScript/Embedded directory and locate the XS file (in the "Vm_a662" subdirectory on my build) generated from duk_perl.c you'll see that the standard perl headers (EXTERN.h, perl.h and XSUB.h) have been included twice.
Also, Inline::C does not handle PERL_NO_GET_CONTEXT and might also not handle NO_XSLOCKS (I don't know).
Both PERL_NO_GET_CONTEXT and NO_XSLOCKS need to be declared before the standard perl headers - and that clearly is not happening.
None of this is causing any breakage, but I recommend that you apply the following changes to duk_perl.c for clarity:

--- duk_perl.c_orig     2022-07-14 12:38:44 +1000
+++ duk_perl.c  2022-07-14 12:40:08 +1000
@@ -1,9 +1,4 @@
-#define NO_XSLOCKS
-#define PERL_NO_GET_CONTEXT

-#include "EXTERN.h"
-#include "perl.h"
-#include "XSUB.h"
 #include "ppport.h"
 #include <time.h>
 #include <stdlib.h>
[download]

If you really want to effectively define PERL_NO_GET_CONTEXT, then we'll need to say goodbye to Inline::C and switch to XS.
For that, I would be using my own InlineX::C2XS (which uses Inline::C) to generate the XS file(s).

Are you happy enough with just those changes to Embedded.pm and duk_perl.c ? ... or do we need to go further ?

Cheers,
Rob

Comment on Re: Need help using Inline::Module with JavaScript::Embedded Select or Download Code

Replies are listed 'Best First'.
Re^2: Need help using Inline::Module with JavaScript::Embedded by cavac (Parson) on Jul 14, 2022 at 12:23 UTC
So that is how to do it! Very, very nice! I've done limited testing so far, but it seems to work exactly the way i wanted it to be. Outstanding job, very much appreciated! I've released a new version on CPAN, should be available on mirrors in a few hours. PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP	[reply]
Re^3: Need help using Inline::Module with JavaScript::Embedded by syphilis (Archbishop) on Jul 14, 2022 at 13:22 UTC
So that is how to do it! Well, it's one way to do it ... but it's a different way to the way it's done in the demo module that ships with the Inline::C source. That demo module is Math-Simple-1.23, and you'll find it in the examples/modules folder in the Inline-C source distro. When you build and install that module (which is safe and fine to do), you'll find that compilation of the C code is done only once (ie during 'make test'), yet nothing is done to control the location of the Inline build directory. I don't know why JavaScript::Embedded is requiring special treatment wrt the location of the _Inline build directory. I think the difference probably lies in some magic provided by Inline::MakeMaker - which the Math::Simple Makefile.PL uses in place of ExtUtils::MakeMaker. But I can't remember and I don't really feel like digging into it. Have a play with Math::Simple if you're interested and you'll quickly see that there's no re-compiling being done. BTW, the problem I had building JavaScript::Embedded on perl-5.36.0 is my fault. The mingw-w64 compiler that built that perl defines _WIN32_WINNT to ~~0x0602~~ 0x0a00, which implies that I'm running Windows 8 10 (and therefore that GetSystemTimePreciseAsFileTime() is available). But I'm actually on Windows 7, and GetSystemTimePreciseAsFileTime() is therefore unavailable does not become available until Windows 8. The mingw-w64 compiler that built my perl-5.34.0 defines _WIN32_WINNT to 0x0502 (which implies pre-Windows7) and therefore avoids the issue. I've released a new version on CPAN, should be available on mirrors in a few hours JavaScript-Embedded-2.7.2 built, tested, and installed fine for me on perl-5.34.0. Cheers, Rob	[reply]


laziness, impatience, and hubris
	PerlMonks