Re^4: Where should (or could) a distribution override HARNESS

"build" refers to Inline creating a module in _Inline (like h2xs) and making it at use/BEGIN time (perl Makefile.PL/make install), before your program runs, ex

subsequent runs don't "build"

unless the c-source changes

The resulting directory structure

The _Inline/build directory usually gets cleaned up, but not for notdef.pl

notdef.pl also NAME's the module, so its name doesn't change, but def.pl doesn't NAME the module, so a name is derived from the filename (def.pl) and the md5 sum of the c-source code

$ cat _Inline\lib\auto\def_pl_4ff5\def_pl_4ff5.inl
md5 : 4ff5a29496365b6167324b7d80efb321
name : def_pl_4ff5
version : ""
language : C
language_id : C
installed : 0
date_compiled : Thu Nov 22 21:58:12 2012
inline_version : 0.5
ILSM : %
    module : Inline::C
    suffix : dll
    type : compiled
Config : %
    apiversion : ?
    archname : MSWin32-x86-multi-thread
    cc : gcc
    ccflags : " -s -O2 -DWIN32  -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICI
+T_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing
 -mms-bitfields"
    ld : g++
    osname : MSWin32
    osvers : 5.1
    so : dll
    version : 5.14.1
[download]

Now, can two copies of notdef.pl run simultaneously? Lets see

First cleanup $ rm -rfv _Inline

And one copy will trip over the other and die , the other will continue normally

Now I'm not sure what scenario davido is talking about in the OP, but I hope this helps

FWIW, def.pl/notdef.pl are derived from XS: returning a 64-bit unsigned int?/Re: Inline::C with multiple *.c

Comment on Re^4: Where should (or could) a distribution override HARNESS_OPTIONS? (use Inline works like this) Select or Download Code


Syntactic Confectionery Delight
	PerlMonks

Re^4: Where should (or could) a distribution override HARNESS_OPTIONS? (use Inline works like this)