Shipping a Perl/Tk App

[tomazos]

(Primer: This node contains sarcasm. The purpose here is of course to ask what is involved in shipping a Perl/Tk app in general, not this specific Hello World example.)

I've written this amazing Perl/Tk application. Here goes:

#!/usr/bin/perl

use strict;
use warnings;

use Tk;

my $mw = MainWindow->new();

$mw->Label(-text => 'Hello, world!')->pack();
$mw->Button(-text => 'Quit', -command => sub { exit } )->pack();

MainLoop;

Wow. Are you impressed? I bet you are.

Now I am ready to ship it. I want to deploy it such that someone can click on a URL and have the application downloaded and installed on Unix, Mac and Windows with a minimum of fuss. My end users may not have Perl and/or Tk installed on their machine.

What are the options? Is it possible to compile the perl interpretter, whatever modules I use and Tk into one bundle and installer?

Also, what are the licensing implications? Can I then charge people for my amazing "Hello Wolrd" application?

[jdtoronto]

For a mixed environment, use PAR to package it. Putting it all in one thing is what PAR does. It includes a Perl interpreter, the necessary modules and your files.

ActiveState's PerlApp fomr the Perl Dev Kit is more flexible and it is what I use for shipping Windows GUI apps.

Check the licences for Perl and the modules - that is the only way you will know.

jdtoronto

[gri6507]

PAR is the answer (you can even cross compile if I remember correctly). Just install it, and run pp --help. Everything should be self-explanatory. The gist of it is

 pp --output=MyExecutable --link=MyExtraLib.so --addfile=MySpecialFile.gif --filter=Bleach MyTkProg.pl

I am not sure about the licencing, but I get it would be something similar to Perl's license, which is to say that charging is still a NoPa.

[jpeg]

At this point I'd suggest you go to java. It's going to be way easier to learn enough java and swing/swt and write a functional applet than it is to monkey around packing perl interpreters for PPC,Sparc,x86 and whatever else AND Tk libs AND Tk.pm into one package AND have it install, configure itself and run without benefits of the make install tests AND deal with the possibility of the user not being able to install software. It sounds like a nightmare.

This is one of the problems java was meant to solve. Java really isn't that bad. Try it.

Update:
Since the code you showed is a hello-world, I'm assuming that your app isn't written yet and you're in the planning stages. If you already have the app written, then obviously my advice isn't reasonable.

[tomazos]

Not to be impolite, but I have done my share of sipping on the Applet/J2SE/J2EE cool-aid but it just won't stay down. One word "ArrayIndexOutOfBoundsException". Imagine what the identifiers look like for the really complicated things like... ah... handling file streams. Its 50 shades of wrong.

Java is slow to write, slow to run and Sun don't let you compile it from source. Its half-open source.

The only supposed good thing about Java is that it stops people from writing difficult to read code by limiting them to spelling everything out in painfully verbose detail.

Or maybe I don't know what I am talking about. Tell me I'm missing something. What is good about Java?

[gri6507]

PAR takes care of all of the packaging issues. It even has packages a perl interpreter. As a result, the deliverable is a single executable that contains EVERYTHING. I don't see why you say it would be a problem. If you mean learning to program is Tk is difficult, then I would tend to disagree, because that's a relative statement. To some learning Java is more difficult that Tk

[jpeg]

Can PAR deliver a single binary that will run on Mac OS, Windows, and any flavor of 'nix? That's how I interpreted tomazos' requirements.