eclipse 3.2 + epic + subversive+cygwin fails

johannesegger wrote on Fri Jan 26 22:00:37 CET 2007:

I've been working on a Perl project for a while, which is stored in a SVN
repository. I decided to try out the Eclipse 3.2 & EPIC.
I installed Eclipse 3.2 SDK, the subversive eclipse plugin. I don't like
activeperl because I don't have MS visual whatever (cl.exe missing) so I
can't use CPAN, and there's some stuff that I need to compile manually for
which there's no bundles (e.g. Sub::Recursive 0.03 and others). 

So I configured EPIC - not much there: I updated my WinXP Env Vars to include
cygwin/bin; I specified the path to cygwin/bin/perl.exe. I set "interpreter
type" to cygwin.

I set up the project as SVN Project, checked out a part of the subtree (that
is written in Perl) called "AEL-Validator" (AEL::Validator), and set it
up as a new Perl project. So far, so good. Worked like a charm. Then the
problems started.

The project uses HTML::TreeBuilder among other modules, so I went into cygwin
and fired up CPAN and installed it (I previously did not develop on my local
machine, this is why the modules were missing). After I've installed the
module, EPIC still complained about not finding them. I looked at the location
of the modules in cygwin: /usr/lib/perl5/site_perl/5.8

I looked at the @INC path
* in EPIC, error message in "Problems". It includes "/usr/lib/perl5/site_perl/5.8"
* cygwin shell, perl -e 'print "$_\n for (@INC)"'. Same.
* I set up a new project, this time local filesystem, not SVN. Same.

This is where the weirdness really starts:
* In the new project, "Test", I can "use HTML::Element" (part of HTML::TreeBuilder
package) and it displays and executes fine. Not so with the other project!
* In the AEL::Validator project, I cannot even run a test file. The test
file includes a line such as "use AEL::Validator". perl can't find a file
within the same project! (you don't need "use lib" for that)
* In Test, I also cannot use AEL::Validator, not even if I use the "use
lib" pragma.
* I've added the path to the AEL-Validator project to @INC under properties
for both projects. No avail, no go. I can also see that this is correctly
"translated" into a cygwin path when I try to execute it. But it won't work!!!

What gives??? :-)


jploski wrote on Fri Jan 26 22:16:51 CET 2007:
1. Get the "problematic" script to work in Cygwin shell
2. Compare the command line used by EPIC to execute the Perl interpreter
which you use yourself. You can see the command line used by EPIC by enabling
"Debug console" in EPIC preferences. This causes additional information
to appear in the log (/.metadata/.log, which you can also open
as Error Log view in Eclipse).

Regarding source code validation working differently in two projects: make
sure that you run "Project/Clean" after you alter @INC path in a project
properties. This clears old entries from the Problems view and reruns validation
on the entire project.

Note that it should NOT be necessary to add any paths from the Perl installation
to the @INC specified in project properties. Also note that you can use
relative paths in the @INC in project properties, and that they will be
then treated as relative to the project root directory.

Having said all that, I'd spend more effort on getting ActiveState Perl
to work in your place... You can install Microsoft's free command-line compiler
kit and nmake to compile stuff from source.
johannesegger wrote on Sat Jan 27 00:46:14 CET 2007:
Thanks for your reply.

1) but it already does. I suppose I should have mentioned that. It's a svn
checkout to a cygwin environment, I loaded all the necessary modules through
CPAN. There's really no reason why it shouldn't work (and it does). To me,
it doesn't look like a problematic module; it looks like something I'm doing
wrong with EPIC (likely) or a bug (?). Some of it is certainly weird, why
would it show a module as being unavailable in one project and not in another?
Also why would a test not be able to load a custom module in the same distribution
- regardless of @INC.

2) Relative paths - what is a path, by default, relative to? workspace?
I added '${project_loc}' to @INC, but that shouldn't make a difference,
should it? I did, and I did Project > Clean after that, and it didn't change

As to ActivePerl. My problem was not having "cl.exe", and I read online
that you have to have Microsoft Visual *** to get that tool (I know you
get nmake for free). Can you point me to a link where I can download the
free command-line compiler kit? Maybe you have some more advice? ;-)

This is my win32 environment, tomorrow I'll try under Ubuntu and see if
that works out better for me.


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