On Jun 7, 2005, at 10:00 AM, Randal L. Schwartz wrote:
In fact, the first thing I thought after hearing about the x86 announcement was "oooh, I hope CamelBones continues to work!".
Of the trouble points I mentioned - a "fat" perl, a tool chain that will build "fat" binaries while running on PPC, and "fat" perl being configured to use that tool chain to build "fat" XS modules - I think it's reasonable to think that either Apple or p5p will deliver those.
The biggest sticking point is libffcall. That's truly key - it provides the crucial piece that allows me to take arguments from Perl's stack, and use them to build up a set of arguments to call objc_msgSend(). Ffcall will need to be updated to understand the Mach- O/x86 calling convention - whatever that is. (I don't think Apple has documented it yet.)
If ffcall doesn't get updated, a switch to libffi is workable - it's not a drop-in replacement, but it works similarly.
So really, the big question isn't really whether CB can continue - I'm pretty certain that it can. The question is whether *I* can afford to continue working on it.
sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
