Re: [gentoo-osx] The road ahead?

[Kito]

On Nov 1, 2005, at 2:45 PM, Grobian wrote:

>
>
> Kito wrote:
>> On Nov 1, 2005, at 2:21 PM, Grobian wrote:
>>> I'm also happy to see this way as an option at least.  I don't
>>> have good arguments yet, but I feel there's more in it somehow.
>>>
>>> On the other hand, (turning my head over to *our* glep42) it
>>> imposes a problem that needs to be addressable somehow by having
>>> the handles to dynamically do the right things depending on apple/
>>> gnu cc-suite, if you get what I mean.
>> Wouldn't extending tc_get* be sufficient?
>
> Probably, but at the moment we already make the wrong assumption of
> doing:
>
> #ifdef __APPLE__
> #include <malloc/malloc.h>
> #else
> #include <malloc.h>
> #endif
>
> and then calling it a darwin patch.  It's an apple patch basically,
> but I don't know the darwin counterpart, if it would exist.

Its the same on darwin. Remember, the saying is 'Never ever try to  
determine if you are on Darwin or OS X, just check for  
functionality". The above example is fine, however this would  
obviously not be:

#ifdef __APPLE__
#include <QuickTime/QuickTime.h>
#endif

As this blindly assumes the proprietary frameworks are available.  
Anyway, I suppose custom defines are always an option too, though I'm  
not sure its really warranted at this point...

>
> What I want to say, is that not only do we need to have the right
> handles to get the data we need, we also need the right methods
> (maybe even configure checks?) to do the right things depending on
> another compiler/linker.

The linker will always be the same for the foreseeable future on any  
Darwin/OS X system, the compiler can and will change however...I  
really would't be too surprised to see them start shipping ICC at  
some point...

> Upstream uses __APPLE__ as well.  We can't expect upstream to have
> support for Gentoo's setup with standard compiler/linker, so if we
> would like to support that I think we should consider using
> conditionals again and/or maybe override some defines the hard way
> to get what we want.
>
> Conclusion at my side of the story is that going the way of using
> (or immitating) Apple's build tools is the one of least resistance
> for now.

Yeah, pretty much my same thought. The big advantage, is since we can  
build from source unlike when relying on Xcode, we can add our own  
goodies to make ebuild maintaining a little easier... the -Wl,-z,now  
situation comes to mind, patching our ld to deal with those options  
would be a far cleaner solution than having to fight it out on -dev@  
trying to get linux folks to change their ways...

--Kito

-- 
gentoo-osx@g.o mailing list