Hi Alfred / Patrick, Thanks for the feedback! Here's some comments - I'm not 100% an expert on this, so please do discuss further :-)
Alfred said: > As I feared: Get Info on a target, Tabbing "General" shows "Type: > Dynamic Library". Will this matter? (probably esthetics) Don't know, > but you could have made a new target based on loadable bundle. I *think* it is just aesthetics (or maybe I missed a setting to change?). I tried starting by making a target based on loadable bundle, but this creates the plist and a bundle folder structure, which we don't need in this case. So instead I went back to my existing UB dylib target and changed the settings to compile as a "bundle" instead. > You would keep the UB-dylib target intact. I don't think it's needed once we have a UB bundle target (see discussion below). > Also, the bundle target in > this context does not have the Perform Single-Object Prelink set. The bundle target in my template *does* have this set - if it isn't set, you get compile errors saying "-single_module or -multi_module flags can only be used when -dylib is also specified". Is this setting not sticking when you use the template? > By > choosing in Xcode for a bundle "starting from scratch" it will > automatically put the bundle executable in a package with a > info.plist file. That is also beneficial if you want to ship the Mach- > O only bundle as an OS-folder package. RB will load this fine as > well. When would you want / need to do this? Since the UB "bundle" part of the plugin doesn't need the usual bundle folder structure and plist in this case, I've followed Jonathan's approach of changing the "Mach-O Type" of the target to MH_BUNDLE, without actually using the folder structure usually involved with a "bundle" target. Is there a scenario where a plugin project *would* need to have the bundle folder structure too? > To put the bundle executable in the rbx volume you need then > simply traverse the hierarchy of the package, and copy the executable > into the rbx format. You will most likely need to adapt plugin > converter to do this traversing. Other than the "Get Info" aesthetics, is there a benefit to doing this extra traversing to pull the file back out of a bundle structure? > If you were to do this then you would have a nice Xcode-starter > plugin that can do a universal dylib, and a universal bundle, with > the additional benefit to ship it also as a packaged bundle. The aim of this template is to be just that - an Xcode-starter plugin template. I'm not sure I see where the packaged bundle comes in. Patrick said: > I am not sure to understand the benefit of keeping a universal dylib > - the universal bundle is where we should have been in the first > place for UB plugins IMO. Universal dylib being only a transitionnal > dead branch in my own understanding. For older versions of RB adding > the PPC carbon plugin target like Dave did in his template would do > it fairly well I guess - or am I missing something important in here? I think Patrick is right here. My understanding is that there's no need to have a Universal Binary dylib at all: * The UB "MH_BUNDLE" type (as opposed to the UB "MH_DYLD" - dylib - type) is supported all the way back to RB 2006r4, the first version to read and use UB plugins * A future version of RB will give an additional benefit of loading these "bundle" plugins to memory * The PPC Mach-O dylib target in my plugin template will be used for 2006r3 and earlier So we only need a PPC Mach-O dylib for 2006r3 and earlier, and a Universal Mach-O bundle for 2006r4 and later. Is that right? Thanks for the thoughts! Dave. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
