Re: Building a large framework
Re: Building a large framework
On 27 Aug 2013, at 16:26, Fritz Anderson <email@hidden> wrote:
> Umm… the time for avoiding complexity is long past: You have thousands of source files.
See below.
>
> 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.
If indexing is deemed to a core activity for the IDE that cannot be gainsaid then so be it.
My current approach is to use a makefile and add the source files to the project as a folder reference.
This gives easy access to the code and prevents any indexing.
The makefile builds all .m files in the source folder by default so the folder reference contains all targeted files.
I haven't quite got the framework link sorted though.
>
> 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.)
I will bear this in mind.
>
> 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.
I am auto generating ObjC bindings for Mono.
The generator reflects on a binary assembly and brings ObjC code forth :
see https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/dotNET/CodeGenerator/Dubrovnik.CodeGeneratorEngine/Net2ObjC.tt
The classes in question represent mscorlib.dll, the assembly that defines the basic system types and structures for .NET.
So I reckon they do all need to be visible in principle. I would gladly reduce the API surface area if possible.
My point about complexity is that I just have a large collection of classes in a vanilla framework. Apart from the size issues it is simple.
Each referenced Mono assembly in a target .NET app will hopefully be represented by an auto generated framework.
So the umbrella may be of use in collecting core frameworks into a single bundle.
User generated assembly bindings will remain standalone.
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