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 13:40:57 -0500
While showering (and believe me, that's not an image you want to linger on), I thought of this:
Create a standalone Xcode framework project with two, and only two files:
MyFramework.h, consisting of a copyright header (if desired), #import <Foundation/Foundation.h>, and maybe a couple of invariant @interfaces — whatever you need that's not generated. Then something like this:
/*************** BREAK BREAK BREAK ***************/
Mark the header as member/public in the framework target.
MyFramework.m: Copyright header, essential additional (non-dynamic) #imports, implementation of the static classes, a break comment as above.
Configure the build settings. Close the project and _never open it in Xcode again._
Start your generation by having sed delete everything after the break comments. Also delete the "f_n" directories I'll mention later.
For each generated public header, append #import "myincludes/f_0/SomeClass.hi" to the header file. The generated headers are to have .hi suffixes, and your generator should distribute them among "f_n" subdirectories it creates, so as not to bring Finder to its knees if you stumble on a header directory.
For each generated source file, append #import "mysource/f_0/SomeClass.mi" to the implementation file. (You could remove the prefix paths if you add myincludes and mysource to the user-includes search path, marked recursive, but my instinct tells me you don't want to make clang do a search at every #import.)
The special .mi and .hi extensions may not be necessary; I haven't thought it through.
The point is: You have an Xcode project whose content never varies. You can use xcodebuild for the build; indexing never happens in the framework build; and client projects need index the header only once. (It would surprise me if xcodebuild did the indexing regardless.) You also get to share an .xcconfig with other projects if you need to keep them all consistent.
No makefile necessary, unless that's how you'd like to organize the actions. If you need to reorganize the build configurations, just do the first part of the process, where the directories and appended #imports are stripped out. Then you can open the project in Xcode without fear. Sounds like a good task for a make pseudo-target.
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.
Investigate using a clang that supports modules. <http://clang.llvm.org/docs/Modules.html> The indexing would be baked-in upon first use, assuming the IDE knows about it. (Let him read who understands.)
But sometimes the only thing I get out of a shower is clean. You'll have to try it out to see if it actually helps. (The technique; showering always helps.) It would be a lot of work just for an experiment, true. It may be no better than your folder-reference solution.
(Defensive disclaimer in case I'm wrong.)
— F
On 27 Aug 2013, at 11:33 AM, "email@hidden" <email@hidden> wrote:
>
> 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
_______________________________________________
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