[Camelbones-devel] CamelBones: Cross-perl portability - comments?

[Sherm P. <sh...@do...>]

Prior to Panther, the difficulties of shipping and supporting an 
application that works with various versions of Perl was the topic of 
much conversation, but it was mostly just theorizing, as Apple had only 
shipped a single Perl configuration to that point. With Panther, it's 
no longer theoretical, and the recent 0.2.1 release of CB attempts to 
address those concerns in the following ways:

1. The framework itself requires the use of an installer, which detects 
one of the two standard Perl configurations as shipped by Apple, and 
installs a framework to match it. I understand that drag-and-drop is 
the preferred means of installation for applications, and once the 
framework is installed, CB apps can in fact be installed that way. 
However, there is ample precedent for using an installer for supporting 
libraries - QuickTime, CarbonLib, MRJ, etc. all use an installer.

2. Version- and architecture-specific directories that are appropriate 
for the perl an app is running under are added to the module search 
path. Thus, an app developer who wants to bundle an XS module with his 
app can now do so, by including multiple copies of the module, each one 
compiled for the perl environments he wishes to support.

Neither of the above attempts to address the case of an advanced user 
who has installed a custom Perl. Such a user will need to build a 
matching framework from source - something that's been simplified a 
great deal by the use of 'make' instead of PB/Xcode to build the 
framework.

The same applies to XS modules; while an app developer can bundle XS 
modules for as many Perl configurations he knows about and wishes to 
provide support for, there still remains the possibility of the app 
being run under an unsupported version or architecture. In that case, 
having failed to find the needed module in the app bundle, Perl will 
continue to search in the normal CPAN directory. So, all that advanced 
users will need to do is install the required module using the standard 
procedure.

In summary, I've tried to find a reasonable compromise. While an 
installer is required for the supporting framework, that's well within 
the realm of the traditional "Mac experience," and once it's done, 
applications can be shipped and installed in any way the app developer 
wants. Modules, both "pure Perl" and XS, can be bundled with an app so 
that a non-technical end user with a "factory" Perl has a hassle-free 
experience. Advanced usage with a nonstandard Perl is somewhat more 
complex but not (in my opinion) unreasonably so, especially in 
comparison to the difficulty of installing such a Perl in the first 
place.

Comments anyone? Do y'all think this compromise is workable for you and 
your users?

sherm--