Re: Building a large framework
Re: Building a large framework
- Subject: Re: Building a large framework
- From: Fritz Anderson <email@hidden>
- Date: Tue, 27 Aug 2013 10:26:01 -0500
Umm… the time for avoiding complexity is long past: You have thousands of source files.
So far as anyone here or on the net knows, your current approach doesn't work, and insisting on it won't make it any worky-er. I join you in hoping someone has an idea on how to do it.
Other work prevents my experimenting, but sub-frameworks are worth a try. Maybe the main project will still try to index the component headers, but if you don't make the framework source visible to the main project / workspace _at all,_ indexing just the headers will at least be an improvement. (But maybe the indexing process isn't as rational as I suppose.)
Do you really need to expose the complete API of all of those classes (if that's what you're doing)? No superclass? Nothing internal — all the methods in the main @interface are unique and essential for external use? No classes that can be hidden in a class cluster? I'm surprised that client code can adapt to thousands of unique class names and selectors.
— F
On 27 Aug 2013, at 4:30 AM, "email@hidden" <email@hidden> wrote:
> To be honest I don't think this is a way forward.
> I don't want to add this sort of complexity (which the docs discourage anyway).
>
> At present I have a Cocoa framework project.
> Adding the auto generated source to the project (or to a new project) causes endless indexing.
>
> So I need to find the best way of getting the auto generated sources compiled and linked into the main framework project.
>
> Regards
>
> Jonathan
>
>
> On 27 Aug 2013, at 06:00, Appa Rao Mulpuri <email@hidden> wrote:
>
>> Hi Jonathan,
>>
>> Divide your large framework in to sub frameworks and bundle them in a Umbrella framework.
>>
>> - Apparao
>>
>> From: "email@hidden" <email@hidden>
>> Date: Mon, 26 Aug 2013 22:57:45 +0100
>> To: <email@hidden>
>> Subject: Building a large framework
>>
>> I am trying to put together a framework that uses a fair amount of generated code.
>> At present the target contains some 2800 generated .m and .h files.
>> I can alternatively generate monolithic output as 1 large (5MB) .m and 1 large (2MB) .h file.
>>
>> Attempting to add the individual or monolithic files to a standard Xcode project results in endless indexing.
>> The googlable tips about turning off indexing don't seem to wash anymore on Xcode 4.6.3
>> Cleaning, rebuilding etc is fairly futile.
>>
>> So I create an external build system project (first draft of makefile is below).
>> Now when I add files to the project it whips through the indexing in a spritely manner.
>>
>> Hopefully the makefile will do the job but it is more tedious to maintain.
>>
>> I would appreciate any insight on getting standard Xcode cocoa projects from choking on large numbers of input files.
>>
>> CC=clang
>>
>> # compiler vars
>> CINCLUDE:= -I/Library/Frameworks/Mono.framework/headers/mono-2.0
>> CFRAMEWORKS:= -F ../../../../../products -F/Library/Frameworks
>> CVERBOSITY:= -v
>> CDEBUG:= -g
>> COBJC:= -x objective-c -arch $(ARCHS) -fexceptions
>> CWARNINGS:= -Wall -Werror
>>
>> # link vars
>> LFRAMEWORKS:= -framework Foundation -framework Cocoa -framework Dubrovnik
>> LLIBRARIES:= -lobjc
>>
>> CFLAGS= $(CWARNINGS) $(COBJC) $(CVERBOSITY) $(CDEBUG) $(CFRAMEWORKS) $(CINCLUDE) -c $(SOURCE)
>> LDFLAGS=$(LLIBRARIES) $(LFRAMEWORKS)
>>
>> SOURCES = $(wildcard *.m)
>>
>> OBJECTS = $(SOURCES:.m=.o)
>>
>> all: $(OBJECTS)
>>
>> Regards
>>
>> 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
_______________________________________________
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