EPIC's handling of @INC

jploski wrote on Sun Oct  2 19:14:26 MEST 2005:

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.

rschumm wrote on Tue Nov 22 10:43:28 CET 2005:

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

kaloyan_iliev wrote on Wed Dec 21 11:11:41 CET 2005:

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. 

jploski wrote on Wed Dec 21 15:13:04 CET 2005:

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.

alexmc wrote on Thu May 18 16:12:03 MEST 2006:

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.

jploski wrote on Thu May 18 19:30:29 MEST 2006:

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.

geek4allseasons wrote on Mon May 22 04:01:43 MEST 2006:

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.

david