Perl packages in folders

lukaskuhs wrote on Thu Oct 16 15:59:26 MEST 2008:

Hello,

I have a problem using EPIC and perl packages in different folders. Perl
(ActiveState 5.10) shows no errors or warnings. EPIC shows an error for
the following:

I have three files:
aaa.pl and
yyy/bbb.pm
yyy/ccc.pm

Now in bbb.pm, the package is named yyy::bbb and in ccc.pm, the package
is named yyy::ccc.

This resulted in an error, because I tried to use package yyy:ccc in package
yyy::bbb. The "import" did not even work out. It could not find the package...

I solved it adding the relative paths to the project's include path. But
this is definitely no solution, but a bug.

Afterwards I though still have warnings: 
--> Name "aaa::some_variable_name" used only once: possible typo

It is not my preferred way to use a global variable from one file in another,
but I need it here, since it is a global flag controlling actions in all
files/modules.

How can I remove the warnings?
Thanks,
Lukas

jploski wrote on Thu Oct 16 18:27:29 MEST 2008:

> I solved it adding the relative paths to the project's include path.

Why do you mention "relative paths" in plural? All you need to add, given
your described directory structure, is ".", which resolves to the project
root directory. I don't view it as a bug. Any directory which you don't
add to project include path explicitly is not in the project include path,
which is as it should be.

Your question about disabling warnings is a Perl question more than an EPIC
question. You can do

{
    no warnings;
    # code which produces warnings
}

lukaskuhs wrote on Fri Oct 17 11:38:34 MEST 2008:

Sorry, I meant path in singular.
So there is a difference between the way my "normal" perl interpreter handles
my perl scripts and the way EPIC handles them? Since with perl on command
line and warnings turned on, I have none of the above mentioned warnings
or errors. Everything runs smooth. In EPIC I chose the same perl interpreter
(exe) as I use on command line. Where is the difference?

Regards,
Lukas

jploski wrote on Fri Oct 17 18:43:32 MEST 2008:

To check your script, EPIC invokes "perl -c [-w] -I 
filename", using the filename's enclosing directory as the working directory
for the perl interpreter. If you do something like "perl -c bbb/yyy.pm"
on the command line, then the working directory is different than in EPIC,
and you may get different results. The -I /path/to/project/root option,
implied by having "." in the project's include path, makes the syntax check
results independent from any working directory.

Note that EPIC checks files individually when you modify them. It is possible
to bring EPIC to show spurious warnings/errors when these errors have been
caused by a referenced file. If you correct the referenced file, EPIC does
not know to check the referencing ones and the errors/warnings stay (until
you touch these referencing files). Alternatively, you can use the Project/Clean
function to make EPIC re-check all files in the project, eliminating any
inconsistencies.

lukaskuhs wrote on Mon Oct 20 13:34:07 MEST 2008:

Thank you very much, Jan.

My problem is, that I never checked the single files, but the project as
a whole, which means, that everything is known to the compiler at this time.
So EPICs check of one file at a time, results in showing me warnings, I
never saw before :-) As a whole, these warnings are to be ignored, as single
file, it is clear, that they must exist. So, this is a hint for me, to reimplement
some parts in a safer / better way.

Thanks for making this position clear. Great support!!!

Regards,
Lukas

dabeat wrote on Tue Jan 20 10:28:10 CET 2009:

Hello,

I think I have a similar problem. I have the same folder and package structure
as Lukas has.

In aaa.pl it is coded, at the beginning:

------------------------
#!/usr/bin/perl -I./yyy

package bbb;
use strict;
use bbb;
------------------------

It works on a unix machine, but with Epic, on Windows XP, the line "use
bbb;" gets a syntax error.

I am not sure, having read the user guide, if it is needed to add the absolute
path to /yyy to the project's path. Anyway I have tested both ways and it
neither works.

Any hint?

Thank you.

dabeat wrote on Tue Jan 20 10:39:01 CET 2009:

I am sorry, what I get is a "compilation failed in require" error.

Thank you,

David