Tips at Re^3: Fail to pp cairo, pango on windows, GTK_BASEPATH, objdump -p blib\arch\auto\Gtk2\Gtk2.dll, build-gtk-glib-post.PL

www.cavapackager.com will probably work

Thanks for those links, Google didn’t quite lead me to them in the past, I’ll look into them when I’m working on this again. The third one seems a bit superfluous with the patches, I think the only thing needed to be patched was Module::ScanDeps, exactly as it was shown there too, compilation of the other stuff worked right out of the box afterwards.

The third one seems a bit superfluous with the patches,

Trust me, nothing was superfluous in 2009

For the "extra" .exe I think you need what is called a "bound file". Read the help (access easiest from the GUI). This will be added in the Files tab. You can configure it to be automatically extracted so that you can just run it from your Perl program. You can also cram in say a config file or some fancy graphic, etc.

In the front pane of the GUI, you can specifiy additional search paths (in addition to the normal Perl directories). I think this will help with your first 2 problems.

When you get this setup, the GUI version can save what you've done as a "project file" so you don't have to keep doing this stuff every time you make the .exe.

Update: As far as the .dll goes, I think that if all else fails, you can use the bound file trick to force it into the .exe package and if its automatically unpacked, I think at run time your program will find it. Congratulations on doing something pretty complicated - you've without doubt already surmounted many hurdles to get this far!

Thanks. We've been using the GUI ever since we've started playing with PerlApp, so we do already have a decent-ish project file for it. I'll look at the File tab more closely for adding the extra file we'd need to run, it might be that I missed some controls there.

However, the other problem doesn't seem to be fixable with the library (blib, shared lib, etc.) list on the main tab, I've tried them and no change in the resulting file (the GTK+ DLLs only began to get included when I copied them to the Perl lib/auto directory). Might be doing something wrong, but adding more paths than the normal ones simply didn't change a thing.

I have just found out that if I do copy the GTK+ libs to the "awkward" directories, the theming will go off in the original Perl script too, not just the packed one. This makes it slightly easier and faster to debug, as long as I can find a way to figure out to see just what kinds of files it tries to open. An open-source Windows strace app I found wasn't of any use, though.

I've never tried to build a GUI library before. I know that when Active State does this, they add extra heuristics to perlApp that makes it "smarter". This is how it can find and force additional modules into the .exe that aren't explicitly "used" (via a use xxx; statement) - there are probably other things that they do of which I am unaware. It may be that you are stuck with some kludgy stuff. I think the "bound file" idea will work and I think I've done it before, but its been awhile. Sorry that I can't help further.

Update: I've used Taskinfo before. It can show files that a process currently has open, I don't know of there is a way to figure out what files were accessed (but are in the steady state closed: i.e. were opened read, but are now closed). The author has continuously updated this app since I first used it- speculation: maybe there is now some kind of "trace" option - I don't know.