Thread: [Camelbones-devel] Embedable framework
Brought to you by:
shermpendley
From: Tom I. <to...@je...> - 2004-11-16 19:40:25
|
I appear to be giving a talk to the London Perl Workshop on Cocoa and Perl programming. To this end, I have a request. I'd _really_ like to be able to produce stand-alone camelbones apps, ie .app bundles with the Camelbones framework embedded inside. I have been utterly unable to build a .framework that works embedded in an application - can someone who understands the build process give me a hand? tom ps - any interesting examples for the talk are welcome - stuff that would be annoying to do without perl _especially_ welcome.. |
From: Sherm P. <sh...@do...> - 2004-11-16 21:41:21
|
On Nov 16, 2004, at 2:39 PM, Tom Insam wrote: > like to be able to produce stand-alone camelbones apps, ie .app > bundles with the Camelbones framework embedded inside. First of all, don't do it. It's a bad idea that's been discussed here before - check the archives. Having said that, if you really must find out for yourself what sort of problems this will cause, try this linker flag: ADDITIONAL_LDFLAGS += -dylib_install_name '@executable_path/../Frameworks' That might help, but I haven't tried it. It's the moral equivalent to Xcode's "install path" setting. > ps - any interesting examples for the talk are welcome - stuff that > would be annoying to do without perl _especially_ welcome.. Web services are particularly annoying if you're using Apple's C/Objective-C API. sherm-- |
From: Tom I. <to...@je...> - 2004-11-17 10:10:40
|
On Nov 16, 2004, at 21:41, Sherm Pendley wrote: > First of all, don't do it. It's a bad idea that's been discussed here > before - check the archives. Having said that, if you really must find > out for yourself what sort of problems this will cause, try this > linker flag: I know all about the badness. But I still feel that replacing the system perl is an act of insanity anyway and you deserve everything you get. > ADDITIONAL_LDFLAGS += -dylib_install_name > '@executable_path/../Frameworks' Woah, CVS head is scary. Things are actually _happening_ in there. Wow. I'll just use the source package, then... I'm seeing "gcc: @executable_path/../Frameworks: No such file or directory" when I try this, and no library is produced. Any ideas? Thanks very much. |
From: Sherm P. <sh...@do...> - 2004-11-17 19:53:42
|
On Nov 17, 2004, at 5:10 AM, Tom Insam wrote: > On Nov 16, 2004, at 21:41, Sherm Pendley wrote: >> First of all, don't do it. It's a bad idea that's been discussed here >> before - check the archives. Having said that, if you really must >> find out for yourself what sort of problems this will cause, try this >> linker flag: > > I know all about the badness. But I still feel that replacing the > system perl is an act of insanity anyway and you deserve everything > you get. I'm 100% with you as far as that goes - but, what about when Apple replaces the system libperl? Is upgrading to Tiger an act of insanity too? >> ADDITIONAL_LDFLAGS += -dylib_install_name >> '@executable_path/../Frameworks' > > I'm seeing "gcc: @executable_path/../Frameworks: No such file or > directory" when I try this, and no library is produced. Any ideas? Did you use single quotes? @ is a special character in the shell, and single quotes prevent interpolation - that's where Perl "borrowed" the idea from. sherm-- |
From: Sherm P. <sh...@do...> - 2004-11-17 21:54:33
|
On Nov 17, 2004, at 5:10 AM, Tom Insam wrote: > Woah, CVS head is scary. Things are actually _happening_ in there. Wow. Dunno whether I should be happy that you noticed, or sad that you're surprised. :-/ Anyway, you're right - CVS head is not for the faint of heart right now. It's at the "it builds clean on my machine, but who knows if it really works" stage. I hadn't planned on mentioning it until I'd sorted things out a little better and done some real testing, but since the cat's more or less out of the bag, here's what's new: The framework and Perl module are built separately now. The module is the usual MakeMaker procedure, and links to the framework. This will allow standalone scripts to use CB, as well as .app bundles. GUI apps still require a .app bundle - that's a requirement of Cocoa, not CB. (I've done some experiments though, that show that the "binary" inside an .app bundle doesn't actually need to be a binary - a script will work too.) Type conversions (id to SV*, etc.) for non-OO functions are now in a traditional XS typemap. I also plan to extend this typemap to include Core Foundation types, using CB's conversion functions and typecasting to take advantage of Apple's "toll-free bridging" of many CF & Cocoa types. There's code in place to register Perl classes with the Objective-C runtime. The registration code builds cleanly and runs without crashing, but creating instances of Perl classes and calling their methods from Objective-C is entirely untested at this point. Code is in place to use ffcall to build up an argument list and call objc_msgSend() to call native methods, instead of NSInvocation. That should be a bit faster, as NSInvocation is basically just a high-level OO wrapper around the low-level function anyway. But more importantly it's needed to support subclassing - there's no way to use NSInvocation in a Perl subclass that wants to call SUPER::whatever(), where whatever() is a native method that's been overriden. But there *is* a low-level function for doing that. I've run some successful tests on this, creating native objects and calling their methods. sherm-- |