>On Wed, Dec 10, 2003 at 04:17:07PM -0500, Morbus Iff wrote: >> Hey all. Just wanted to report a success story with PAR. >> I've long (since 2001) been using Perl2EXE to build >> AmphetaDesk, a crossplatform RSS reader that has >> been downloaded 100,000+ times. > >Heya! I'm one of the 100,000+ users, and I'm very >happy that you find PAR helpful. :-)
Actually, I've got a problem - I may have jumped the gun.
Last night, I built a skeletal version of AmphetaDesk: ultimately, it was the framework for creating other applications that used an internal web server, a templating system, and a Windows specific OS libraries. It worked great and all was well. The fact that it was Windows-specific is key (see below0.
This morning, I just tried to build a full-fledged copy of AmphetaDesk (everything above, plus a bunch of XML related modules and XS code for the RSS parsing), and it doesn't seem to work. When I click on the .exe, I can see AmphetaDesk.exe show up briefly in the process list, then I can see par.exe show up briefly, then nothing.
One of the things AmphetaDesk does is to redirect STDERR so that I can log everything in a local file for non-DOS friendly end-users. Checking that shows:
Can't locate AmphetaDesk/OS/Windows.pm in @INC (@INC contains: CODE(0xd05914) CODE(0xff0994) .) at C:\Documents and Settings\morbus\Desktop\ AmphetaDesk\lib/AmphetaDesk.pm line 108.
Now, you'll have to trust me that AmphetaDesk/OS Windows does exist. Two things that are red-flags.
* @INC does not show a full path to AmphetaDesk/lib,
which it should. Somehow, it works, since it's
pulling in AmphetaDesk.pm.* The fact that it broke on the GUI loading.
When you download AmphetaDesk, you're downloading all of the code for every OS I currently support, OS/Linux.pm, OS/Windows.pm, OS/MacOS.pm, and OS/MacOSX.pm.
When you first run AmphetaDesk, it attempts to determine which of those modules to load based on Perl's $^0, as per this bit of code:
if (get_setting("app_os") =~ /Win/) {
require AmphetaDesk::OS::Windows;
import AmphetaDesk::OS::Windows;
}
elsif (get_setting("app_os") =~ /Mac/) {
require AmphetaDesk::OS::MacOS;
import AmphetaDesk::OS::MacOS;
MacPerl::Quit(3);
}And so on. Somehow, that's breaking. I use "require/imports" for the obvious reason that I determine the OS at runtime, not compile time, where "use" happens.
I suspect, as a side-effect, that the modules that AmphetaDesk::OS::Windows uses (Win32::API, ::GUI, and ::TieRegistry) are also not found by Module::ScanDeps. Checking the output of a -v5 confirms that, and that's really A-OK. Hunting around for required/imported stuff would break my system anyways (as you'd attempt to load Mac::InternetConfig, which would never exist on anything but a Mac installation).
So, forcing a "use" in the main script of the above three Win32 modules correctly adds them to the .exe, but I still get the @INC error mentioned above, which still confuses me greatly.
Deliberately "breaking" the GUI lookup system and adding "use AmphetaDesk::OS::Windows" to the top of AmphetaDesk.pm (the same module that does the require/import) works perfectly.
Any thoughts? Why are my local "use"s being found, but not my local "require" and "import"s?
Again, note, that this is with the following:
use lib;
use FindBin qw($Bin);
use File::Spec::Functions;
BEGIN { unshift(@INC, catdir($Bin, "lib")); }Changing that to use lib './lib'; causes the same error.
-- Morbus Iff ( i put the demon back in codemonkey ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
