para - epic eclipse

Una forma adecuada de usar módulos personalizados Perl dentro de otros módulos Perl

Question

Estoy usando módulos personalizados en mis scripts y tengo que almacenarlos fuera del directorio lib de Perl. Entonces en los scripts de Perl ( *.pl ) utilizo el siguiente bloque para incluirlos en @INC :

BEGIN {
  use FindBin qw($Bin);
  push @INC, "$Bin/../ModulesFolder1";
  push @INC, "$Bin/../ModulesFolder2";
}

Pero también tengo que usar módulos dentro de mis otros módulos Perl ( *.pm ), y como entiendo, FindBin funciona para scripts. Entonces cambio ese bloque a:

BEGIN {
  push @INC, catdir( dirname( $INC{''ThisModule.pm''} ), qw( .. ModulesFolder1 ) );
  push @INC, catdir( dirname( $INC{''ThisModule.pm''} ), qw( .. ModulesFolder2 ) );
}

Funciona pero con un pequeño problema. Codigo en Eclipse con el complemento EPIC, y "si tiene algo en un bloque BEGIN que hace que el compilador aborte prematuramente, no informará errores de sintaxis a EPIC" , de modo que pierdo la verificación de sintaxis de Perl en los módulos.
Entonces, con FindBin (en scripts) no tengo que usar ninguna función (como catdir ) en BEGIN{} block, y la verificación de sintaxis del siguiente código se realiza correctamente. Además, me gustaría no cambiar ninguna variable de entorno (como PERL5LIB ), para poder utilizar las secuencias de comandos en las máquinas de mis colegas sin ninguna preparación adicional.

¿Cuál es la forma correcta de utilizar módulos Perl personalizados dentro de otros módulos, y no interferir con la verificación de sintaxis EPIC al mismo tiempo? ¿O tal vez incluso debería incluir módulos de otra manera?

Answer 1

Configure la variable de entorno PERL5LIB . Cada vez que utilice o requiera, Perl revisará todos los directorios que figuran en él.

Alternativamente, coloque todos los módulos personalizados necesarios en el directorio del script, para que pueda usar rutas relativas en use lib . También le permitirá crear rápidamente un paquete para transferir todo a otra PC simplemente empacando recursivamente desde el directorio de nivel superior.

Answer 2

Estoy totalmente en desacuerdo con la modificación de @INC en los módulos. Causa todo tipo de dolores de cabeza. Deje que el script (o incluso el proceso de llamada a través de la variable de entorno PERL5LIB ) se configure correctamente en @INC .

script.pl :

use FindBin qw( $RealBin );
use lib
   "$RealBin/../ModulesFolder1",
   "$RealBin/../ModulesFolder2";

use ModuleInFolder1;

ModuleInFolder1.pm :

use ModuleInFolder2;  # Works fine.

En cuanto a EPIC, haga lo siguiente:

1. Haga clic derecho en el proyecto.
2. Propiedades
3. Perl Include Path
4. ${project_loc}/ModulesFolder1 , Agregar a la lista
5. ${project_loc}/ModulesFolder2 , Agregar a la lista

(Literalmente me refiero a los 14 caracteres ${project_loc} . Eso significa algo para EPIC. Continuará funcionando incluso si mueve el proyecto).

PS - $RealBin es mejor que $Bin porque le permite usar un enlace simbólico a su secuencia de comandos.

PS - __FILE__ es más apropiado que $INC{''ThisModule.pm''} .

Answer 3

No estoy seguro acerca de Eclipse, pero puede usar use lib (probablemente no funcione, cambia @INC en tiempo de compilación) o establecer la variable de entorno PERL5LIB para que apunte a la (s) carpeta (s) de su biblioteca.

Answer 4

Otra solución (de mi colega): un cambio que se realizará en el módulo:

sub path_to_current_module() {
  my $package_name = __PACKAGE__ .''.pm'';
  $package_name =~ s#::#/#g;

  for my $path ( @INC ) {
    # print "/$path == ''$path''/n";
    if ( -e catfile( $path, $package_name ) ) {
      return $path;
    }
  }

  confess;
}

BEGIN {
  my $path_to_current_module = path_to_current_module();
  push @INC, catdir( $path_to_current_module, qw( .. ModulesFolder1 ) );
  push @INC, catdir( $path_to_current_module, qw( .. ModulesFolder2 ) );
}

Parece que a la manera antigua (descrita en la pregunta), Perl no pudo ubicar el nombre del módulo actual en @INC , es por eso que el error perl -c fue interrumpido dentro del bloque BEGIN . Y el sub descrito lo ayuda a determinar la ruta real al módulo actual. Además, no depende del nombre del archivo actual y se puede copiar a otro módulo.