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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 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
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To check your script, EPIC invokes "perl -c [-w] -I <project include path> 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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
> 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
}
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
To check your script, EPIC invokes "perl -c [-w] -I <project include path> 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.
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
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.
I am sorry, what I get is a "compilation failed in require" error.
Thank you,
David