On Fri, Nov 26, 2010 at 11:05 AM, Matt Sergeant <matt@...> wrote:
> On Fri, 26 Nov 2010, Sherm Pendley wrote:
> Thinking through the implications of Matt's comments, it seems necessary
>> allow app authors to override the versioner setting. For instance, if a
>> has set their user default to 5.8.9, but an application uses given/when,
>> app *must* ignore the user default because it *can't* run on the specified
>> Perl version.
> Can't CB just build (and ship) a perl 5.12 that is compatible with (as far
> back as you like, but I'd target say Tiger), and then just use that?
Yes, that's the plan for 2.0, for the framework to include its own Perl,
entirely doing away with the need for "support bundles." Before that can
happen, though, all of the bridge code needs to be moved out of the
framework and into the module. As it stands, the module links against the
framework; if the framework were to embed a particular version of Perl, then
trying to build the module for another Perl would result in the module being
linked against two different libperls at the same time.
For now, I want to focus on the easiest way to allow 1.1.2 to support the
5.10 that's included with Snow Leopard. Yes, it's an ugly hack, but so is
the whole "support bundle" scheme, so for 1.1.* we're kind of stuck with it.
(I suppose we could include Perl 5.12 with a dynamic libperl, and a support
bundle for it as well as support bundles for all of the Apple-supplied
Perls... but that's just making an ugly mess even uglier... I don't want to
For now, as a quick-n-dirty hack to allow 1.1.* to support Snow Leopard's
5.10, this is what I've come up with:
App developers can include a CamelBones.plist in their app's resources, with
a CBSupportedPerls key that lists (suprise!) the Perl versions supported by
that app. For example, if you use given/when, your app would require 5.10
(and, by extension, Snow Leopard), so your app's CamelBones.plist would look
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "
If no CamelBones.plist is found, the list of supported Perls is assumed to
be as before - 5.10.0, 5.8.9, 5.8.8, and 5.8.6.
Then, if a value for the key "Version" is found in the
com.apple.versioner.perl defaults domain, that value is checked for in the
list of supported Perls. If it's a supported version, it's used; otherwise
it's ignored. So, if your app requires 5.10 because it uses given/when, but
the user has set /usr/bin/perl to prefer 5.8.9 with the versioner key, your
app will ignore that requested and use 5.10 anyway. But, if you've taken no
special steps to make your app require a specific Perl version, it will run
under whatever the versioner key asks for.
Finally, as always, the key "perl" in the "org.camelbones" defaults domain
will override all of this. Set it to "/usr/bin/perl5.8.6", and that's
exactly what all of your CamelBones apps will (try to) use, even on Snow
Leopard. Few (if any) end users will use this; it's intended for developers
who have installed the "Perl SDKs" on Snow Leopard, and want to test their
apps against an older Perl version than CamelBones would have selected on
Cocoa programming in Perl: