Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
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??


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

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?
  • Download Code

Replies are listed 'Best First'.
Re^3: Where should (or could) a distribution override HARNESS_OPTIONS?
by afoken (Abbot) 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

      $ 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

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1005189]
help
Chatterbox?
[ELISHEVA]: the data source, or one of them, is the OECD - they provide a *lot* of data that ought to be easily available to perl programmers.
[erix]: it might be cunning to mention the module in the title... :)
[ELISHEVA]: fancy that - a title that actually describes the problem :-)
[ELISHEVA]: but actually thanks for the reminder
[Discipulus]: DBI::CSV + utf8 = BOO?M
[erix]: in extremis we tend to forget stuff ;)
[ELISHEVA]: \Disciplus : lol
[Discipulus]: and ELISHEVA we waait one your post since ~2years... ;=)
[ELISHEVA]: has it really been that long?
[Discipulus]: it seems..

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (7)
As of 2017-05-28 20:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?