On Thu, 9 Nov 2006 11:10:24 -0800 (PST)
Fred Moyer wrote:

> On Wed, 8 Nov 2006, Perrin Harkins wrote:
> > On Mon, 2006-11-06 at 12:28 -0600, Frank Wiles wrote:
> >> What I have always done is package my applications as if they
> >> are CPAN modules using ExtUtils::MakeMaker or in more recent
> >> days Module::Build. Never had a problem with it, but it probably
> >> isn't suited to distributing apps to novice users.

> >
> > We do the same sort of thing here, with an automated build script
> > that builds apache, mod_perl, and our modules from source. You can
> > see some work on generalizing that for others to use here:
> > http://sourceforge.net/projects/matchstick

> I like this approach, but it still requires a perl binary to make
> everything happen. The default perl compile on a lot of systems out
> there is threaded, and built for general use. Have you found a way
> of shipping a custom perl build in addition to all the other
> components?
> Over a year ago I wrote a variation on what you described, but
> additionally it bootstrapped perl from source, then build apache,
> mod_perl, and the modules. Bootstrapping perl from source was
> troublesome, and generally sucked - everything else worked fairly
> well. I've been experimenting with building a perl rpm for redhat,
> but I've found that to be less than painless to build one that
> provides a second binary in addition to the system binary. Any
> thoughts?

Look at the code for SqueezeBox at slimdevices.com. It's not
only a great product, but they have some pretty decent packaging
for Windows, Mac, and Linux. While they don't send a custom
Perl with it, they do send some custom modules and modify @INC
to make sure you use their versions of certain CPAN modules.

But in any case, with a decent packaging system ( outside of
Perl's I would wager ) it wouldn't be hard to build a Perl for each
of your target platforms, include it in your package, and then make
sure all of your code references that special Perl.

I believe this is how Sophos' PureMessage installs itself. Basically
putting your own Perl binary and module paths in
say /usr/local/myapp/bin/perl. This is probably the best way to
ensure you have full control over everything about your application.

Frank Wiles