I guess one caveat I might make about the Test::Compile::Internal module is that it tests for successful compilation by using the perl executable (and its associated set of module libraries) that was specified in the shebang line of the script that called it. I'll call it the "tester script" for purposes of the rest of this post.

If I have multiple Perl installations, the script being tested (i.e., any of the Perl scripts that the Test::Compile::Module locates in various directories) might have a shebang line that specifies the perl executable (which of course has an associated set of module libraries) that is different from the one on the shebang line of the tester script.

My goal is to see whether the tested script compiles correctly under the perl executable that's going to be compiling and running it -- the one specified on its shebang line. The tested script might be called in the middle of the night by a cron job, or Apache calls it via CGI, or a user enters its path and name at a Linux command line. Here's where a problem arises: If my tester script uses different perl executable/libraries than the tested script, and a particular module has been installed in the Perl libraries used by the tester script but not in the Perl libraries used by the tested script (because I forgot to install it, for example, which might happen if I've upgraded the Perl installation I'm wanting the tested script to run on), the tester script would cheerfully report that the tested script successfully compiles. But in fact it will fail when it's called in practice. A similar problem would arise if a particular module used by a tested script already is correctly installed but it has NOT been installed in the libraries of the tester script (e.g., a CPAN module that's not part of the core modules in the Perl installation under which the tester script is running and has never been installed manually). In that case, the tester script will report that the tested script failed to compile, when in fact it will fail when it's called in practice.

Would it make sense for the Test::Compile::Internal's code to be modified so that it scrapes the shebang line of the tested file in order to determine and then run the Perl executable (and its corresponding set of Perl libraries) to do the compilation test? Perhaps in most cases there will be no difference between that shebang line and the tester script's shebang line, but sometimes not.

In reply to Re: Bulk check for successful compilation by davebaker
in thread Bulk check for successful compilation by davebaker

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.