@INC problem with large project

mherger wrote on Tue Jun 26 16:41:49 MEST 2007:

I'm trying to use EPIC to work on SlimServer (http://www.slimdevices.com).
Although I've added _all_ subfolders I still get error messages about "Compilation
failed in require". While the line isn't underlined any more, there's still
the red bullet to the left of it.

Should EPIC be able to manage a project of that size?

jploski wrote on Tue Jun 26 20:18:21 MEST 2007:
Your problem is likely not related to the project size or EPIC at all. Search
this forums for tips on resolving @INC problems (particularly manual invocations
of "perl -c" for diagnosing them). One more hint: under Windows, do NOT
use backslashes in paths, use forward slashes instead.

BTW, you should not have to add all folders to @INC with any sensible project
structure, just the roots of the trees in which the *.pm files are located.
mherger wrote on Wed Jun 27 17:58:30 MEST 2007:
Thanks! Though I have searched the list before posting, I didn't know about
that perl -c diagnosis. Will give it a try.

mherger wrote on Wed Jun 27 18:57:39 MEST 2007:
That really helped - to find the explanation in the SlimServer code itself...
It comes with it's own collection of CPAN modules. But some of them are
installed in different versions on my system, resulting in a version conflict
when loading XS modules.

Is there a way to reverse the path search order (custom path before system
@INC)? I'd need to first look inside SlimServer's own CPAN folder before
perl searches the system's library path. 

Thanks for the pointer.
jploski wrote on Wed Jun 27 19:11:10 MEST 2007:
The default behavior of Perl is that paths provided by -I take precedence
over the built-in path. So all you need is add the custom CPAN folder to
your @INC in EPIC. You can easily find out the effective include path by
running this script: foreach my $i(@INC) { print "$i\n"; }

Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.