Just another Perl shrine PerlMonks

### Re^2: Where should (or could) a distribution override HARNESS_OPTIONS?

by davido (Archbishop)
 on Nov 22, 2012 at 22:09 UTC ( #1005189=note: print w/ replies, xml ) Need Help??

Thanks for pointing this out.

You could very easily be right with respect to gcc being allowed to run in parallel. That means we've got another problem. I can't speak for Inline::C's test suite, but I can say that no Inline::CPP test is intentionally reliant on any other test. And to answer your question, Inline::CPP generates within an _Inline directory a new subdirectory for each build's files. Nevertheless, there must be some resource that is getting clobbered, and I should be investigating that instead of looking for a means of preventing parallel testing. More research needed in that area, it seems.

Let's put the Inline::CPP example aside for a moment then, and let the original question stand without any strong example of a module that fits that infinitesimally small category. :)

Dave

Comment on Re^2: Where should (or could) a distribution override HARNESS_OPTIONS?
Replies are listed 'Best First'.
Re^3: Where should (or could) a distribution override HARNESS_OPTIONS?
by afoken (Prior) on Nov 23, 2012 at 05:30 UTC
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". ;-) "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 : ?
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

Create A New User
Node Status?
node history
Node Type: note [id://1005189]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (11)
As of 2015-11-30 22:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
Voting Booth?