Re: Opinions wanted: CamelBones packaging

[Sherm Pendley]

On Monday, November 4, 2002, at 05:37 PM, Robert Mah wrote:

On 11/4/02 7:23 AM, "Sherm Pendley" <[EMAIL PROTECTED]> wrote:

I'm close to the 0.3 release, and I've been thinking about the question
of packaging.
[...]

It would be wonderful if you could package multiple builds of app specific
and non-standard modules in your .app bundle and link to the installed
libperl.dylib. You would pass the appropriate library dir with the -I
option when calling perl_parse(). This method would create small
application bundles that can (with a bit of extra effort) run with many perl
versions if the developer so chooses.

Unfortunately, it wouldn't.

Applications that link against libperl.dylib have the same limitation as compiled XS modules - they only work with the version of Perl they're linked against.

But, placing it in /Library/CamelBones would mean
that the app cannot be installed by simply copying it in the finder.

The stuff in /Library/CamelBones/ would only be needed on the developer's machine. It would be used as a source to copy modules from, when placing them into the .app bundle.

At run-time, assuming you're going to use a little miniperl.c that creates a
PerlInterpreter object which runs the application perl code...

Actually, it's a quite a bit more complicated than that... In 0.3, Perl objects are full peers, accessible as objects with callable methods from Objective-C. Perl classes can inherit from Objective-C classes, and vice-versa. And, you can extend existing Objective-C classes by adding new Perl methods to them.

But people could probably live with a HOW-TO which describes
the rather minor changes to the traditional 'perl Makefile.PL; make; make
install' build process for modules

Developers could, but secretaries, designers, and grandmothers couldn't.

sherm--

If you listen to a UNIX shell, can you hear the C?