richardamb wrote on Mon Jan 22 16:32:19 CET 2007:
If I create a project as follows: Project name: Test create dir: perl create file: perl/tools.pm --cut-- package tools; sub hello { print "hello\n"; } 1; --cut-- create dir: perl/subset create file: perl/subset/subtool.pm --cut--- package subtool; sub hi { print "hi\n"; } 1; --cut--- create file: test.pl --cut--- #!/usr/bin/perl use tools; use subset::subtool; tools::hello(); subtool::hi(); --cut-- Set the project preference Perl include path to include ${project_loc}/perl All syntax checks pass, and the script runs.. but if in test.pl i put the cursor on tools::hello and press F3, I jump to the tools.pm file if I put the cursor on subtool::hi and press F3 I get the error: "Could not locate module file for package subtool" any ideas what I am doing wrong... Thanks.
jploski wrote on Mon Jan 22 18:36:32 CET 2007:
I guess you should have "package subset::subtool" instead of "package subtool" there.
richardamb wrote on Tue Jan 23 10:23:01 CET 2007:
Hmmm.. but the perl is valid.. my project is rather large and I just moved it to EPIC, there are around 100 packages and many many calls to each, I really don't want to change every file.
jploski wrote on Tue Jan 23 19:31:29 CET 2007:
> Hmmm.. but the perl is valid.. Is it? When you write a statement like use foo::bar; and have a file foo/bar.pm which just contains "package bar;", what you achieve is { require foo::bar; # ok import foo::bar; # meaningless, package foo::bar does not exist } Unless can provide arguments why it makes sense and why you can't use "require" directly, I'm reluctant to extend the current "go to package" implementation (which relies on a conventional package name to file mapping through @INC) to support your case.
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.