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

[afoken]

[...] but I have found that gcc doesn't seem to support parallel compiling. If two test scripts cause the C/C++ compiler to be invoked at the same time, we get a test failure. I don't think our chances are strong for getting that fixed.

That sounds really strange. When I run make -C/usr/src/linux -j5, several instances of gcc can run in parallel without trouble. So, what is different in Inline::C and Inline::CPP? (I really don't know. The Inline::* modules are still on my TO DO list.) Trivial question: Does each test have its own set of configuration files, gcc input files, gcc output files, gcc temp files?

Alexander

[davido]

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. :)

[afoken]

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

[Anonymous Monk]

"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

$ perl -le " system 1, $^X, q,notdef.pl, for 1,2 "

$ validate Stage
Starting Build Preprocess Stage
get_maps Stage
Finished Build Preprocess Stage

Starting Build Parse Stage
validate Stage
Starting Build Preprocess Stage
get_maps Stage
Finished Build Preprocess Stage

Starting Build Parse Stage
Finished Build Parse Stage

Starting Build Glue 1 Stage
Finished Build Parse Stage

Starting Build Glue 1 Stage
Finished Build Glue 1 Stage

Starting Build Glue 2 Stage
Finished Build Glue 2 Stage

Starting Build Glue 3 Stage
Finished Build Glue 1 Stage

Starting Build Glue 2 Stage
Finished Build Glue 2 Stage

Starting Build Glue 3 Stage
Finished Build Glue 3 Stage

Starting Build Compile Stage
  Starting "perl Makefile.PL" Stage
Finished Build Glue 3 Stage

Starting Build Compile Stage
  Starting "perl Makefile.PL" Stage
Writing Makefile for modSV
Writing Makefile for modSV
Writing MYMETA.yml and MYMETA.json
Can't open Makefile for input: No such file or directory
 at notdef.pl line 8.
BEGIN failed--compilation aborted at notdef.pl line 8.
Writing MYMETA.yml and MYMETA.json
  Finished "perl Makefile.PL" Stage

  Starting "make" Stage
  ...

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