--- 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]

--- 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]

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

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

When the test suite is run for the first time, Inline::C performs its required compilation before the tests run. When the test suite is run for the second time, no compilation is done and the existing compiled binaries are used.

Sorry for the slightly off-topic questions ahead, but I am still a beginner, learning Perl.

So, I want to understand this a little bit better. So, when inline C is used, the compiler saves the binaries. How does Perl know not to compile it again? And where does the compiler save the binaries when done? Is it in /tmp/ramdisk or is there a specific directory for Perl inline C binaries? How are these binaries named? Are they given random names?

Your questions are answered in the Inline documentation, see the section "How Inline Works".

In brief:

How does Perl know not to compile it again?

Any change to the C code (including changes affecting only whitespace) will be detected as a change to the MD5 fingerprint, and the code will only then be recompiled.
Changes to Inline configuration options will not alone trigger a rebuild - unless it's the FORCE_BUILD option that is being changed to a TRUE value.

And where does the compiler save the binaries when done?

Generally the building is done in ./_Inline/build and the binaries saved in ./_Inline/lib, but the name of the parent directory is configurable.

How are these binaries named?

A combination of the filename of the script, and the leading hex digits of the MD5 fingerprint of the code section.

Cheers,
Rob

ExtUtils::MakeMaker's Makefile.PL has a postamble sub where you can specify things to be injected into the produced Makefile. In theory you can add Makefile code to compile and install your binaries as your module is make'ed. That would be permanent. But as anonymous monk said, quickest way would be to find the XS produced and just include it in your distribution (somehow! I am a novice of XS, I can not tell you how).

BTW, when I even do whichpm JavaScript::Embedded it takes ages (18sec) to complete! 100x more than other modules.

BTW2, my compiler complains that croak(msg) (in fatal_handler of produced XS) needs a format and this croak("%s", msg) keeps it happy. Is that an Inline::C issue I wonder (perl 5.32/linux almost latest) hint-hint syphilis.

bw, bliako

BTW, when I even do whichpm JavaScript::Embedded it takes ages (18sec) to complete! 100x more than other modules.

Yes - I think it's just silently compiling the Inline::C code first.
IMO, the Inline config should specify build_noisy => 1, so that we can see what's happening (or, at least, that *something* is happening).
It also needs to specify a build directory something like directory => "$Config{installsitelib}/_Inline", in order to avoid the re-compilation issue cavac mentioned.
There's a bit to work through.

BTW2, my compiler complains that croak(msg)....

I haven't noticed that ... something else to check.

Cheers,
Rob