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

Inline::CPP generates within an _Inline directory a new subdirectory for each build's files.

What is a "build" in this context? I.e. do we have one subdirectory per invokation of a test script, one subdirectory per test script, or one per Inline::CPP version? How are the names of the subdirectories calculated (what are the input parameters for the function that returns the subdirectory name)?

Idea behind the last question: two test scripts, both use a common module that uses Inline:CPP, subdirectory name depends only on that module. Two gccs fight in the same subdirectory.

(I should really install some Inline::* modules. But it's 6:30 am and it will be a long day at $work. No time for fun ...)

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re^3: Where should (or could) a distribution override HARNESS_OPTIONS?

Replies are listed 'Best First'.
Re^4: Where should (or could) a distribution override HARNESS_OPTIONS? (use Inline works like this) by Anonymous Monk on Nov 23, 2012 at 06:28 UTC
"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 <Reveal this spoiler> 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	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Where should (or could) a distribution override HARNESS_OPTIONS? (use Inline works like this)
by Anonymous Monk on Nov 23, 2012 at 06:28 UTC

"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

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

[reply]
[d/l]
[select]