EPIC's handling of @INC

Jan Ploski
  • Jan Ploski
    Jan Ploski

    I would like to change the way how EPIC sets the Perl include path for script compilation/execution/debugging. Because my proposed change is not backwards-compatible, I ask for some developer and user feedback.

    Here is how it works today (undocumented, but true):
    1. EPIC adds ALL folders of your project to the include path.
    2. It also adds the paths you specified in project's preferences literally (that is, without translating them to absolute paths).
    3. Script file's parent folder is used as the working directory for compilation and execution.

    Suppose you have a project with folder "scripts", in which you keep your *.pl files, and a folder "lib", in which you keep your modules. If you think like me (or come from the Java world), you would add "lib" to the include path in project's preferences and assume you are all set to go. After all, compilation and execution now work fine, don't they?

    Well, they do, but not because of your settings. EPIC has implicitly included "lib" and "scripts" (and "doc", and "junk", and "CVS", and "lib.bak" and any other folders it happened to find in the project). Your "lib" reference does not hurt, but given that the scripts are executed in "scripts" as working directory, it is also completely ignored.

    Instead, I propose the following behaviour for constructing the @INC path:
    1. Add only folders specified in project's preferences.
    2. Always treat relative paths in project's preferences as project-relative, not relative to the script's parent folder.

    Simple and compatible with the classpath interpretation used for Java projects. Of course, this change would break the @INC path for some existing ("misconfigured") projects that rely on the current magical undocumented behaviour.

    Protest now if you disagree that the change would be worth the initial annoyance caused by it.

    • Rémy Schumm
      Rémy Schumm

      I had missed this one: since nobody answered, I will: yes, do this, that's a very good idea.

    • Kaloyan Iliev
      Kaloyan Iliev

      Can the include paths be relative at all.
      I have some projects and include paths in the includepath file are not relative. When I commit the project to CVS and other user check it out the includepath is not working properly.

      • Jan Ploski
        Jan Ploski

        In the current "testing" version of EPIC (0.3.12), you can try entering a project-relative path by specifying it as ${project_loc}/some/path. Maybe it will work for you, however I have been getting exceptions at times because evaluating ${project_loc} depends on which file is currently selected in the workspace (if none, an exception occurs).

        In the future, relative paths will be treated as project-relative automatically.

    • Alex McLintock
      Alex McLintock

      What is the status of this ?

      I am trying the current (but old) stable EPIC on Eclipse v3.0 ON Windows with ActiveState perl 5.6

      It seems to be ignoring the project preferences where I tell it the perl include path and JUST using the one built into the ActiveState perl binary.

      • Jan Ploski
        Jan Ploski

        Well, the "stable" version of EPIC is outdated and not maintained by anyone. I would recommend switching to the unofficial epic-devel version, however, it only works with Eclipse 3.1 and later. So you may be out of luck with your problem.

        • I am having similar problems finding modules with EPIC installed with easyeclipse 1.0 beta LAMP edition and the latest version of ActivePerl.

          I have not had time to do much testing. After revisiting Perl documentation I want to look at platform path conventions. The old "/" vs "\" issue.

          Site directories are C:/Perl/...... EPIC project paths set through the dialogue are C:\.....\....
          as displayed in the source tab error tooltip.

          Adding an extra directory level to the project path might trigger path conversion. The lib module man page indicates that unix conventions are the default. The require section in perlfunc has perl code described as representing require semantics. It uses a constant '/' separating directory from module name.

          @INC manipulation in BEGIN block in the source module doesn't seem to have an effect on the value used by EPIC. The next step is using a siteconfig file.

          The debugger breakpoint should be definitive. I know more about Perl then Java. I am hoping a few stabs in the dark will get things working.