Re: Ensure Framework Links to static lib not dylib
Sandor Szatmari
Thanks Jack, yes, your point is well taken… but, these are in house production apps/frameworks and we have a long running well establish deployment design that works well…
toggle quoted messageShow quoted text
The structure is as follows Cocoa App/Frameworks… (with statically linked external libs) are hosted on /Network/Applications and /Network/Frameworks. These shares are pushed out via the OpenDirectory master. Then all clients who are part of the domain automagically have all the components they need with deployment being limited to a single point. Keeping the frameworks out of the apps means replacing one copy of the framework if making a change that does not require pushing out the apps too. I know it’s mostly a moot point… and certainly the horse is dead at this point. We do embed our frameworks within app for qc purposes for updates/new features. This makes an encapsulated bundle for testing that finds it’s frameworks internally before looking at the other runtime framework search paths. For external libraries that can change version based on an OS update/Security Update, I link them statically so there is no question the frameworks/apps are using the correct external resources for which QA/testing has been performed and certified. So, this is the point at which we embed, albeit statically linked embedding, code from one source inside another source. Sandor
On Dec 10, 2020, at 14:29, Jack Brindle via groups.io <jackbrindle@...> wrote:
|
|