Re^2: How to manage the transfer of large Perl environments from one network to another

Yes, regarding PERLLIB, you read it right. To be exact, there are 439 entries, which collectively radiate cold shafts of broken glass in every direction imaginable. :-/

Could you kindly shed some light on what you mean by a test suite? I am asking because, typically, Perl scripts are run to initialize a chip-building environment by parsing configuration files and settings, etc., and then a non-Perl compiled binary is fired up for what can sometimes be a multi-day run. Now, I could skip the non-Perl compiled binary activity for testing purposes. The different Perl scripts, though, are run from one wildly different location to another. Are you saying a master/test Perl script should be used to appropriately augment @INC as each chip-building Perl script fails? In other words, at the start of test suite activity, empty @INC and build it out to include only what is necessary.

Pardon my ignorance, but I am not familiar with setting up test suites in Perl. Typical Perl scripts that I author, for example, require only a handful of custom modules, so this is turning out to be quite the learning experience for me...

Comment on Re^2: How to manage the transfer of large Perl environments from one network to another

Replies are listed 'Best First'.

Re^3: How to manage the transfer of large Perl environments from one network to another
by hippo (Bishop) on Mar 29, 2019 at 22:37 UTC

Could you kindly shed some light on what you mean by a test suite?

As luck would have it I am currently trying to produce a gentle introduction to testing in Perl. ~~You can read the work in progress on my scratchpad.~~ (Update: This document has now been published as Basic Testing Tutorial). In essence a test suite is a set of code which verifies how some other code is expected to behave. Ordinarily this is barely little more than a sequence of subroutine or method calls with associated test data but in your case can be as simple as trying to compile a catalogue of scripts. Your Perl scripts will either compile or not but you can (presumably) attempt to compile them without running and thereby do no damage.

Are you saying a master/test Perl script should be used to appropriately augment @INC as each chip-building Perl script fails?

Not exactly. The test suite is there just to test and should be idempotent. You could, if you so wish, construct another script to perform the augmentation and then subseqently use the test script to assess its effectiveness. Test scripts (and suites) exist for a number of reasons but regression is not the least of them. If you adjust $PERLLIB to fix one script you must ensure that doing so does not break another. This is one of many areas where automated testing proves its worth.

[reply]


There's more than one way to do things
	PerlMonks