Peter N Lewis wrote:
[snip]
One alternative is to change from unit "uses" to include files (which the Mac interfaces support anyway for reasons I've never understood),
It is to get behavior similar to THINK Pascal's uses propagation. The includes bring in all the declarations needed to effectively use the unit's interface without having to list the indirectly dependent units in the uses clause.
In essense, it is a combination of C header mechanisms with Pascal's unit mechanics. In effect, it is a poorman's implementation of Extended Pascal's import and export parts without all the fine grained control features like renaming and selective imports and exports. To make it work, though, the compiler has to be able to propagate compiler variable defines through the uses clause chain to avoid a boatload of redunant compiles and multiple redeclarations. I have the impression that GPC doesn't support that sort of compiler variable propagation so Apple's unit and include file methods and organization isn't going to work.
and just make a single really really big unit including all the interfaces. However that would be quite large and I don't know how happy GPC will be with a single unit with 300,000 lines in it, or how slow it will be for users to use it once the .gpi has been created.
I don't think it would be much different than using the Carbon framework with CodeWarrior. The initial compile (on the order of 170,000 lines) is noticeable but not inordinately slow. From then on you're using a cached precompiled unit similar to a .gpi and it isn't even noticeable.
I'll try some experiments, but if anyone has any suggestions, I'm all ears.
You might wamt to see how it effects linking and dynamic library loading also. I sure wouldn't want to hit every framework library just for a simple sysbeep call.
Gale Paeper gpaeper@empirenet.com