-----BEGIN PGP SIGNED MESSAGE-----
email@example.comAm I understanding you correctly that with the new relocatable
(Sherm Pendley) wrote:
>Would it be unreasonable to just build a static libperl 5.10 using GCC 4,
>the 10.5 SDK and a 10.3.9 deployment target, and link that directly to
Perl 5.10 we can now essentially embed Perl in CamelBones and be
completely independent from whatever Apple has shipped (both
backwards and forwards)?
So an application embedding CamelBones.framework will have a
complete, independent, Perl 5.10 and be deployable (currently)
Yes, exactly. Also, you could embed libperl.dylib by itself, with no framework, if you just need Perl's raw C API. SVs, AVs, and HVs - oh my. P5p gets the credit - there was a push a while back to make perl relocatable, in the sense that the initial defaults for privlib, sitelib, and vendorlib wouldn't be hard-coded into the binary. Instead, they'd be relative to libperl, so that the whole package could be moved around as a unit.
So now, in the new world of things, you'd link your app against libperl.dylib, and copy it into your app in Contents/MacOS. Then, you'd either import the standard Perl headers in CORE/, or import and link against the CamelBones bridge framework. Either way, whether you use the plain C or bridged ObjC interface, the CoreModules/, CPANModules/, and Resources/ will be your default privlib, sitelib, and vendorlib, respectively.
That sounds almost too good to be true (well, apart from every
CamelBones app dragging around a complete Perl install, but
thems the breaks I guess). :-)
It's not as bad as one would think at first. Libperl.dylib is 2.8MB or so, although it'll get bigger if we add 64-bit support for intel and/or ppc. Beyond that, all you need to bundle is the modules your app actually uses. There's no need for you to pack 16MB worth of man pages, for instance, into your app bundle.
You might not know what standard modules your app will need at compile time. You won't, for example, if you allow users of your app to write plugins that can run arbitrary Perl code. Even in that situation, there's a lot of pruning that could be done when the Perl install tree is embedded in your app. I doubt your users really need 16MB of man pages or 6MB of POD docs, for instance.
Another thought - only one copy of any XS modules that are included is needed now, where before developers had to download two complete sets of Perl to build their modules against, and ship three copies of them (some of which are universal, so doubled in size themselves) with their apps, to achieve the same kind of portability.
When we start bundling XS modules like DBD::*, we'll save a substantial amount there, by not having to bundle everything in triplicate.
Also, there's Apple's known stand towards Perl updates in their OS - security patches only, not even a minor point upgrade. Mac OS X will have Perl 5.8.8 until 10.6 is released. And Apple is slowing the pace of their OS development - they announced a while back that it would be 18-20 months between releases now. I suspect that a lot of CamelBones users will want to use 5.10 in their apps sooner than that.