[wx-dev] wxCocoa trunk link failure

[Stefan Csomor]

Hi

>> DE> I think it is downright wrong to exclude UNIX code where there
>> is no
>> DE> alternative so I moved stackwalk.cpp and epolldispatcher.cpp to
>> DE> BASE_UNIX_AND_DARWIN_SRC.  The former will compile and work on
>> Leopard
>> DE> systems.
>> 
>> I share Stefan's worry about what is going to happen if you compile
>> under
>> Leopard but want to run it under Tiger though?
> 
> It will be Leopard-only for sure.  My best theory as to how to correct
> this is to configure against the older SDK so the config tests don't
> pick up features not present in older releases.  You can then of
> course simply change the SDK path in the Makefile so that when you
> build you have the newer headers available.  Any UNIX bits that aren't
> present will have already been turned off by configure tests and the
> Carbon/Cocoa code can use tricks like weak-linking or
> respondsToSelector: to determine at runtime whether or not the newer
> API is available.
> 
> If a few people would try this and have it work then perhaps we can
> add a --with-configure-macosx-sdk in addition to the current --with-
> macosx-sdk that would allow you to do as follows:
> 
> Configure against 10.4 SDK, make against 10.5 sdk
> configure --with-configure-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk
> --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk
> 
> Configure against 10.4 SDK, make against system headers:
> configure --with-configure-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk
> 
> If --with-configure-macosx-sdk is empty then the value from --with-
> macosx-sdk will be used which will keep the behavior of --with-macosx-
> sdk the same as it is now.  If --with-configure-macosx-sdk is used but
> not --with-macosx-sdk then the library will be configured using an SDK
> but built without an SDK at all (e.g. system headers).
> 
> The alternative is to reverse that and make --with-macosx-sdk the one
> used by configure then add a --with-make-macosx-sdk to specify an
> alternate SDK for build.  I don't particularly like it though because
> building against the latest system headers is actually preferable to
> building against an older SDK.  That is to say that there should be a
> way using only one flag (IMO --with-configure-macosx-sdk) to configure
> the library against an SDK then not use it when building.  Changing
> the behavior of --with-macosx-sdk to be used by configure but not by
> default for build is probably not a good idea.
> 
> The third option is to have three options.  Add the new --with-
> configure-macosx-sdk and --with-make-macosx-sdk options and have the
> existing --with-macosx-sdk set both.  This is of course not much
> different from my first proposal which is to add --with-configure-
> macosx-sdk only.  The only real difference is that --with-make-macosx-
> sdk becomes a first-class option.  I don't think it's needed though so
> my choice is to simply add --with-configure-macosx-sdk.

couldn't we reuse the --with-macosx-version-min ? to me it seems to expose
exactly the same basic situation, the minimum system it should run on, so it
should be used for configure IMHO

Best,

Stefan