#254 @INC update problem

Core (65)

I am running Eclipse v3.1 on openSuSE v10. I installed
the latest version of the EPIC plugin. I used CPAN and
the shell to add the PDL module to Perl, add the
directory to @INC, and verify that the information in
@INC was updated. When I create a script with "use
PDL;" Eclipse/EPIC generates the following error:
"Can't locate PDL.pm in @INC." It also shows the
contents of @INC. The problem is that the contents of
@INC displayed by Eclipse/EPIC do not match the
contents listed when using the shell. BTW, I have
also tried to push the path of the new directory onto
@INC from inside Eclipse/EPIC, and I have tried the
"use lib path" approach. Under no circumstances does
Eclipse/EPIC find the PDL.pm file even though it is
there. Any ideas?

Duane Armstrong


  • Jan Ploski

    Jan Ploski - 2006-04-13

    Logged In: YES

    You should try setting the @INC path in project properties.

  • Curtis Fletcher

    Curtis Fletcher - 2006-04-25

    Logged In: YES

    Running Eclipse(3.1.2)/EPIC(grabbed automatically from
    org.epic.updatesite) under XP I'm editing a project on a
    develoment webserver shared using samba. The position of the
    includes on the dev server is "/home/pharma/lib" which is in
    each script in the form "use lib" however when accessing
    using Eclipse/EPIC over the share the libs would be in
    "Z:\lib" adding this to the perl include path in project
    properties does not seem to effect the syntax checker as it
    still reports it cannot find the modules in the problem pane
    and @INC is shown as not including Z:\lib. I'm guessing this
    is the same problem.

  • Jan Ploski

    Jan Ploski - 2006-08-05

    Logged In: YES

    Can you still reproduce this problem in 0.4.0?

  • Jan Ploski

    Jan Ploski - 2007-06-03

    Logged In: YES
    Originator: NO

    There are problems with paths containing backslashes in the @INC under Windows. As a workaround, you should use slashes instead of backslashes in Windows paths.

  • Matt Hilliard

    Matt Hilliard - 2007-06-27

    Logged In: YES
    Originator: NO

    I've come across a similar problem:
    If I call

    use FindBin;
    # possibly more complicated search paths than this get created based on 13 years of gruesome logic
    use lib "$FindBin::Bin/..";

    Epic completely disregards the use lib statement.

    setting @INC path in project properties cuts it to a point, but
    ordering or simply availability of include paths results in different behaviours at runtime for different machines and environments--it would be nice having the editor run the same way as the script itself, and not have to configure and juggle the paths for 50 copies of Eclipse (juggling the environments is hard enough)

  • Jan Ploski

    Jan Ploski - 2007-06-27

    Logged In: YES
    Originator: NO

    Provide an example to demonstrate your problem (I'm checkingin EPIC 0.6.11).

    This works fine for me.

    use lib "/tmp";

    This also works:

    BEGIN { $foo = "/tmp"; }
    use lib "$foo";

    And this


    use FindBin;
    use lib "$FindBin::Bin/..";

    use Blah;

    with a test script located at foo/bin/test.pl and the package Blah at foo/Blah.pm

    There is no reason why EPIC would disregard use lib statements, as it simply invokes "perl -c" to check the script.

  • Csaba Szepesvari


    I had the same problem on Mac OSX.
    However, I figured that my command line interpreter was
    while in the IDE, the interpreter used was
    In the EPIC preferences of the IDE I changed the perl interpreter to be used from 'perl' to '/opt/local/bin/perl', and I also moved away /usr/bin/perl and created a symbolic link to /opt/local/bin/perl (my preferred perl installation).
    This solved the problem and my script happily runs.
    Maybe one of these steps alone would also be sufficient, but I did not test this.

    Hope this helps.
    - Csaba


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks