On Fri, Nov 26, 2010 at 11:05 AM, Matt Sergeant <matt@sergeant.org> wrote:
On Fri, 26 Nov 2010, Sherm Pendley wrote:

Thinking through the implications of Matt's comments, it seems necessary to
allow app authors to override the versioner setting. For instance, if a user
has set their user default to 5.8.9, but an application uses given/when, the
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 go there.)

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 like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>CBSupportedPerls</key>
        <array>
            <string>5.10.0</string>
        </array>
    </dict>
    </plist>

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 its own.

sherm--

--
Cocoa programming in Perl:
http://camelbones.sourceforge.net