#635 running Test::More upsets DynaLoader in hg project

open
nobody
Core (65)
5
2011-09-21
2011-09-21
Anonymous
No

I have a hg (mecurial) project and I started making xyz.t test cases using Test::More. Running locally it is ok but often generating a new run configure every time giving me alot of xyz.t (12) unless I press one of the X:s after every turn.

When trying to run the xyz.t files inside a pulled mercurial project I get:

Use of uninitialized value $DynaLoader::dlsrc in string eq at /usr/lib/perl/5.10/DynaLoader.pm line 56.
Use of uninitialized value in split at /usr/lib/perl/5.10/DynaLoader.pm line 61.
Use of uninitialized value $DynaLoader::dl_dlext in concatenation (.) or string at /usr/lib/perl/5.10/DynaLoader.pm line 153.
Use of uninitialized value $DynaLoader::dl_dlext in regexp compilation at ../../lib/DynaLoader.pm (autosplit into ../../lib/auto/DynaLoader/dl_findfile.al) line 284.
Use of uninitialized value $DynaLoader::dl_dlext in concatenation (.) or string at ../../lib/DynaLoader.pm (autosplit into ../../lib/auto/DynaLoader/dl_findfile.al) line 284.
Use of uninitialized value $DynaLoader::dl_so in regexp compilation at ../../lib/DynaLoader.pm (autosplit into ../../lib/auto/DynaLoader/dl_findfile.al) line 285.
Use of uninitialized value $DynaLoader::dl_so in concatenation (.) or string at ../../lib/DynaLoader.pm (autosplit into ../../lib/auto/DynaLoader/dl_findfile.al) line 285.
Use of uninitialized value $DynaLoader::dl_so in concatenation (.) or string at ../../lib/DynaLoader.pm (autosplit into ../../lib/auto/DynaLoader/dl_findfile.al) line 286.
Use of uninitialized value $DynaLoader::dlsrc in string eq at ../../lib/DynaLoader.pm (autosplit into ../../lib/auto/DynaLoader/dl_findfile.al) line 287.
Global symbol "%Config" requires explicit package name at /usr/share/perl/5.10/Time/Local.pm line 35.
Global symbol "%Config" requires explicit package name at /usr/share/perl/5.10/Time/Local.pm line 38.
Compilation failed in require at /usr/share/perl5/HTTP/Date.pm line 12.
Compilation failed in require at /usr/share/perl5/LWP/UserAgent.pm line 12.
BEGIN failed--compilation aborted at /usr/share/perl5/LWP/UserAgent.pm line 12.
Compilation failed in require at /usr/share/perl5/RPC/XML/Client.pm line 40.
BEGIN failed--compilation aborted at /usr/share/perl5/RPC/XML/Client.pm line 40.
Compilation failed in require at /home/jim/workspace/RegSysCore/src/RegistrarSystemCore/Commands.t line 13.
BEGIN failed--compilation aborted at /home/jim/workspace/RegSysCore/src/RegistrarSystemCore/Commands.t line 13.

while running it locally at the prompt - no problem, nor a problem when moving the file back to a locally stored project.

Discussion

  • Jan Ploski
    Jan Ploski
    2011-09-21

    You can avoid generating a new launch configuration every time. The proper way to do it is to set up the launch configuration once through Run > Run Configurations...,and later to use the drop down menu of the green "Run" icon to select from among the recently launched scripts. It's also good to set "Always launch the previously launched application" in Run/Debug Preferences, so that you can relaunch a script by simply clicking the Run icon.

    Re your problem: You can get the exact command line which EPIC uses to execute a script if you turn on "Debugger console - experimental" in Preferences. The full command line is then logged to workspace/.metadata/.log (which you can probably also access through the Error Log view) Try running that command line from shell to see if you can reproduce the bad effect. If you cannot, then the difference must be either in the working directory or the set of environment variables passed down to the script in both cases. If env vars are the culprit, you should either define the needed ones individually in the launch configuration, or take care that they are set for the Eclipse process.

     
  • JimNo
    JimNo
    2011-09-21

    Errors could be repeated with debug log showing:

    perl -I/home/jim/workspace/.metadata/.plugins/org.epic.debug -I/home/jim/workspace/RegSysCore/src/RegistrarSystemCore -w -Mautoflush_epic /home/jim/workspace/RegSysCore/src/RegistrarSystemCore/Commands.t

    What seems to be the problem a include not made by me:
    -I/home/jim/workspace/RegSysCore/src/RegistrarSystemCore

    With out it works:
    perl -I/home/jim/workspace/RegSysCore/src -I/home/jim/workspace/RegSysCore/test -I/home/jim/workspace/.metadata/.plugins/org.epic.debug -w -Mautoflush_epic /home/jim/workspace/RegSysCore/src/RegistrarSystemCore/Commands.t
    1..1
    test
    # No tests run!

    I only want the manually added paths to my src and test folders - is my setup wrong?

     
  • Jan Ploski
    Jan Ploski
    2011-09-21

    Is /home/jim/workspace/RegSysCore/src/RegistrarSystemCore your project base dir or perhaps the working directory specified in the launch configuration? Have you checked that the Include Path in project properties doesn't contain unnecessary entries?

     
  • JimNo
    JimNo
    2011-09-21

    I've tested some more, and last include is the working directory

    If I change the default working directory to '${project_loc}' it works - how ever this takes time for every perl file I want to run if default behaviour can't be changed? Especially if I click on run button and it generates a new run configuration even if I had a old one (I didn't find the 'Always launch the previously launched application' in Run/Debug
    Preferences. Run/Debug Settings (Project -> Properites) is empty and options as New... Duplicate, Edit.. and Delete are disabled and Restore Defaults didn't give any details.

     
  • Jan Ploski
    Jan Ploski
    2011-09-21

    The option is under Window > Preferences > Run/Debug > Launching.

    As mentioned, you shouldn't be creating a new launch configuration every time you run a script. The "Run As" option from context menu should only be used once, after that use the Run icon and it's drop down menu. In the Run > Run Configurations... dialog you can clone existing configurations, including the working directory (and change the configuration name and script to be executed). There is no way to change the default to be different than ${resource_loc} (it's hard-coded). You could use a wrapper script instead of /usr/bin/perl as your interpreter, then you inject all sorts of magic before the script is executed.

     
  • JimNo
    JimNo
    2011-09-21

    I found the configuration. Thanks for quick feedback. Solution is a bit less flexible than standard behavior (without me writing that wrapper) but I can at least work now. Thanks!