Re: Building a large framework
Re: Building a large framework
- Subject: Re: Building a large framework
- From: Dan Korn <email@hidden>
- Date: Wed, 11 Sep 2013 14:28:55 -0700
- Acceptlanguage: en-US
- Thread-topic: Building a large framework
I know this thread is a little old, but I just wanted to mention that I had to take a similar approach of building basically a "dummy" stub library to link to, which was swapped out for a real library (a dylib in this case) at runtime.
This was (still is) a C++ project, not Objective-C, but the problem is that the linker in Xcode wants to resolve the runtime link dependencies, with all of the @loader_path stuff, just to link, but I don't have that whole relative bundle structure set up with all the linker paths fixed up with install_name_tool until after the binaries are built and then all placed in their relative locations in the actual finished bundle. It all seems to work fine if you have one binary linking to one dylib, but if you have that dylib linking in turn to a second dylib, the linker wants to use the runtime dynamic loader to resolve things.
The only way I could figure out to escape that Catch-22 was to just link to a dummy stub library which exported functions with the same signatures as my real dylib.
Here's the thread with more explanation:
http://lists.apple.com/archives/xcode-users/2008/Jun/msg00698.html
Obviously it's an old thread from the ancient days of Xcode 2, but I think the same issues still apply now. (And of course, I still maintain that it should be up to the client of a dynamic library to decide where it wants to locate a library that it's using and embedding in its own bundle, rather than the dylib dictating a location to the main application or executable, as in the old Unix days where everything was just dumped into someplace like /usr/bin. You can use install_name_tool works to get around most of these issues, but it's still an Ugly Hack. Just tell the runtime loader to find the library where I'm telling you to put it in the bundle, Xcode!)
Anyway, what I did back then seemed congruous to Fritz's suggestion.
Dan
On Aug 27, 2013, at 4:20 PM, email@hidden wrote:
> On 27 Aug 2013, at 19:40, Fritz Anderson <email@hidden> wrote:
>
>> While showering (and believe me, that's not an image you want to linger on), I thought of this:
> Bath time is a critical component in all the best software projects. The agile guys missed a trick there.
>
>>
>> Create a standalone Xcode framework project with two, and only two files:
>>
>> /*************** BREAK BREAK BREAK ***************/
>>
>> Good stuff removed here.
>>
>> I have no idea whether xcodebuild would choke on such a monolith. You could do the same divide-and-conquer trick with separate .h/.m files for portions of the whole. Have lots and lots of RAM.
>>
> Adding this level of indirection is a neat trick and it turned out to be pretty trivial to try this out in my case.
> My code generator can spit out 2 such monolithic .h and .m files that represent the entire framework (it can also spit out class sized code lumps too).
>
> Even with the just the two host files present (the monoliths are included in the hosts) Xcode goes into Got to get this stuff indexed pronto mode.
> Xcodebuild eschews the indexing and just gets on with the building but chokes up on the 100,000 or so LOC.
>
> The divide and conquer trick - say having 100 host m files might work but its trickier to setup. I may try this tomorrow though.
> Having individual .m and .h files makes for friendlier browsing too.
>
> The ideal would be to run xcodebuild on a .pbxproj file that the code generator dynamically updates (using /usr/libexec/PlistBuddy ?)with the 100s of .m files to be built.
>
> Time to run some hot water…
>
> Thanks
>
> Jonathan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden