Re: Using PAR: risk assessment

[jplindstrom]

I haven't used the Win32::SerialPort module, but PAR works well with e.g. Win32 and Win32::GUI.

The biggest problem I've had with programs like PAR and PerlApp is their inability to statically (at build time) determine which modules dependencies there are, but that's something you encounter and then figure out for that application.

The usual risk management strategies say: experiment as soon as possible. Build a prototype with all the modules and kinds of functinonality you need (e.g. threads) and try it out.

/J

[Anonymous Monk]

FYI: The latest version of PerApp from ActiveState ( PDK 6.0 )has a GUI interface !

It WILL show, AND it will allow you to manage module dependencies in a tree view... as well as additional files you might want to be bound into the exe.

you can add modules to a trim list, and you can manually add modules to be included if needed.
It does a good job grabbing most modules required ( and dll's ).

It also adds a new in-memory DLL loader option.

and it also allows you save these settings in a project file..

[Jenda]

I've never been a big fan of fancy GUIs. There are some things I do like in the new PDK, but I doubt I'll ever use this particular GUI. I'll stick to my PDKcompile.

For the original question: I do have a few multithreaded Perl apps packed using PerlApp. Never had any problems with the threads that'd be related to the packing.