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

[Anonymous Monk]

in reply to Re^3: Where should (or could) a distribution override HARNESS_OPTIONS?
in thread Where should (or could) a distribution override HARNESS_OPTIONS?

"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

<Reveal this spoiler or all spoilers in this node or all in this thread>

subsequent runs don't "build"

unless the c-source changes

<Reveal this spoiler>

The resulting directory structure

$ tree -f -a _Inline
_Inline
|-- _Inline/build
|   `-- _Inline/build/modSV
|       |-- _Inline/build/modSV/INLINE.h
|       |-- _Inline/build/modSV/MYMETA.json
|       |-- _Inline/build/modSV/MYMETA.yml
|       |-- _Inline/build/modSV/Makefile
|       |-- _Inline/build/modSV/Makefile.PL
|       |-- _Inline/build/modSV/blib
|       |   |-- _Inline/build/modSV/blib/arch
|       |   |   |-- _Inline/build/modSV/blib/arch/.exists
|       |   |   `-- _Inline/build/modSV/blib/arch/auto
|       |   |       `-- _Inline/build/modSV/blib/arch/auto/modSV
|       |   |           |-- _Inline/build/modSV/blib/arch/auto/modSV/.
+exists
|       |   |           |-- _Inline/build/modSV/blib/arch/auto/modSV/m
+odSV.bs
|       |   |           `-- _Inline/build/modSV/blib/arch/auto/modSV/m
+odSV.dll
|       |   |-- _Inline/build/modSV/blib/bin
|       |   |   `-- _Inline/build/modSV/blib/bin/.exists
|       |   |-- _Inline/build/modSV/blib/lib
|       |   |   |-- _Inline/build/modSV/blib/lib/.exists
|       |   |   `-- _Inline/build/modSV/blib/lib/auto
|       |   |       `-- _Inline/build/modSV/blib/lib/auto/modSV
|       |   |           `-- _Inline/build/modSV/blib/lib/auto/modSV/.e
+xists
|       |   |-- _Inline/build/modSV/blib/man1
|       |   |   `-- _Inline/build/modSV/blib/man1/.exists
|       |   |-- _Inline/build/modSV/blib/man3
|       |   |   `-- _Inline/build/modSV/blib/man3/.exists
|       |   `-- _Inline/build/modSV/blib/script
|       |       `-- _Inline/build/modSV/blib/script/.exists
|       |-- _Inline/build/modSV/dll.base
|       |-- _Inline/build/modSV/dll.exp
|       |-- _Inline/build/modSV/modSV.bs
|       |-- _Inline/build/modSV/modSV.c
|       |-- _Inline/build/modSV/modSV.def
|       |-- _Inline/build/modSV/modSV.o
|       |-- _Inline/build/modSV/modSV.xs
|       |-- _Inline/build/modSV/modSV_def.old
|       `-- _Inline/build/modSV/pm_to_blib
|-- _Inline/config-MSWin32-x86-multi-thread-5.014001
`-- _Inline/lib
    `-- _Inline/lib/auto
        |-- _Inline/lib/auto/def_pl_38b1
        |   |-- _Inline/lib/auto/def_pl_38b1/def_pl_38b1.bs
        |   |-- _Inline/lib/auto/def_pl_38b1/def_pl_38b1.dll
        |   `-- _Inline/lib/auto/def_pl_38b1/def_pl_38b1.inl
        |-- _Inline/lib/auto/def_pl_4ff5
        |   |-- _Inline/lib/auto/def_pl_4ff5/def_pl_4ff5.bs
        |   |-- _Inline/lib/auto/def_pl_4ff5/def_pl_4ff5.dll
        |   `-- _Inline/lib/auto/def_pl_4ff5/def_pl_4ff5.inl
        `-- _Inline/lib/auto/modSV
            |-- _Inline/lib/auto/modSV/.packlist
            |-- _Inline/lib/auto/modSV/modSV.bs
            |-- _Inline/lib/auto/modSV/modSV.dll
            `-- _Inline/lib/auto/modSV/modSV.inl

18 directories, 35 files

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

<Reveal this spoiler>

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

<Reveal this spoiler>

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