Re: [Pyobjc-dev] building on 10.1.5

[Ronald O. <ous...@ci...>]

On Saturday, Nov 2, 2002, at 17:54 Europe/Amsterdam, bb...@ma... wrote:

> On Saturday, November 2, 2002, at 11:27 AM, Steven Majewski wrote:
>> Has anyone been able to build pyobjc on 10.1.5 ?
>
> It won't build on 10.1.5 right now.
To be more precize: The core objc module/package should build just 
fine, but the wrappers for functions in Cocoa contain 10.2 specific 
code.

>
>> Using the default compiler, it always seems to die while
>> trying to compile register.m.
>
> Ugh-- shouldn't be doing that!  Definitely a compiler bug.

Does it fail due to the size of the file or for some other reason? If 
the compiler on 10.1.5 doesn't like the size of the file we could split 
it into smaller parts.

>
>> I saw some notes on the list about problems with the file being so
>> large, so I tried using gcc3 to build ( Is this what's standard on
>> 10.2 ? ) -- it compiles register.m without problem but runs into
>> a load of errors later on.
>
> The automatically generated files have loads of references to 10.2 
> specific variables and API.  This could be fixed.
>
> All of the new-to-10.2 APIs are surrounded by #ifdef blocks and, as 
> such, could be conditionally removed.   It would be a matter of:
>
>     - augmenting the generation scripts to deal with this
I'm not sure if the current scripts maintain enough state to make this 
easily possible.

BTW. The current scripts were meant to be temporary: Just a quick hack 
to have something until I built the real wrappers (probably using 
bgen). I never got to the second step :-(

>
>     - adding the generation scripts to the overall module build 
> process [Ronald indicated that there are bugs in the generator 
> scripts, but I don't know what they are]\
There's 1 buglet that I know of: The last time I generated new wrappers 
I had to manually remove a definition (IIRC a constant). I didn't check 
why this was necessary, but this is probably fixable by adding more 
#imports to one of the files.
>
>     - passing the header files to be processed by the generators 
> through CPP with the appropriated -D flags to cause 10.1 or 10.2 
> specific builds [or, simply build the 10.1 binaries on a 10.1 > machine].
I'd build the 10.1 binaries on a 10.1 machine, just in case a 10.2 
build picks up some unwanted dependencies. And you'll have to test the 
binaries on 10.1 anyway, actually building doesn't take too much time.

On the other hand: On 10.2 you can some pre-existing macros to hide 
10.2 specific definitions, this should make it easier to build 10.1 and 
10.2 binaries from one set of sources.

Ronald