apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barry Scott <ba...@barrys-emacs.org>
Subject Re: Mac OS X Universal builds and APR
Date Thu, 22 Oct 2009 19:47:42 GMT

On 20 Oct 2009, at 22:30, Jeff Trawick wrote:

> On Tue, Oct 20, 2009 at 4:54 PM, Barry Scott <barry@barrys- 
> emacs.org> wrote:
>> On 20 Oct 2009, at 04:18, Branko ─îibej wrote:
>>> Barry Scott wrote:
>>>> I think the problem is that configure is used to find out things  
>>>> that
>>>> change arch to arch
>>>> like void * size rather then using preprocessor detection of those
>>>> things.
>>> I wonder, how do you detect the size of void* with the  
>>> preprocessor in
>>> C? The preprocessor doesn't understand sizeof.
>> You detect that its a build on mac os x and then use the CPU  
>> feature macros
>> that the compiler defines to choose 4 or 8. You end up writing code  
>> like
>> this:
>> #ifdef __APPLE__
>> #ifdef __x86_64__
>> its Mac intel 64
>> #endif
>> etc...
>>>> Testings for API functions being present would be arch independent.
>>> That depends, doesn't it? There's no guarantee that you have the  
>>> same
>>> external libraries available in several different flavours.
>> If you are talking about Mac OS X features then yes you have the  
>> same libs
>> on all arch.
> A vendor might provide an interface on a subset of architectures.  A
> vendor might have a architecture-specific bug in an interface used by
> APR that would result in APR needing to disable its use for the
> affected architecture build.  I wouldn't bet that Apple is in a class
> by itself with regards to these issues.  (I recall that we had to
> disable the use of some OS feature for 64-bit mode in the past, though
> not on OS X.)
> APR-util more obviously uses features that aren't OS features and are
> packaged by groups with different philosophies.  Maybe you only have
> Oracle/MySQL/whatever client libraries for one architecture.

Indeed Apple might have a bug that you wish to work around by having
config detect the issue. But this is not the common case on the Mac as
far as I have experienced. (I only got bitten by an API being completely
missing on 10.4 power PC - very obvious as the code failed to build for
one arch.)

Why not consider having configure work in two modes:

A) As it does now, build one arch. This should be the default.
B) do a universal build with a list of arch of the users choosing
      I have to explicitly choose this mode.

(B) means that the people that package for the Mac have a
greatly simplified life.


View raw message