foo-append working with merger in muniversal?

[Ned Deily]

In article <1284432064.30731.1394857159 at webmail.messagingengine.com>,
 "Michael Dickens" <michaelld at macports.org> 
 wrote:

I should preface my comments here with the disclaimer that, while I am 
somewhat familiar with MacPorts port files as a user, I am not an 
experienced MacPorts developer nor am a numpy user.  However, I am 
intimately familiar with the dirty details of building, installing, and 
testing Python on OS X in general, and I do use MacPorts pythons (among 
others).

> I've been hacking on py26-numpy to try to get +universal working.  I can say 
> from my experiments that:
> 
> (1) MacPorts' installed gcc4[3-5] do not honor "-m32 -m64" at the same time; 
> just one or the other.  The only way to get build for multiple architectures 
> using this gcc is to build them separately and them use "lipo" to join any 
> binary files.  Hence, the "muniversal" group must be used.

As far as I know, only the Apple-supplied gcc and friends support the 
multiple -arch values to do a universal build in one pass.

> (2) The "muniversal" group does not know how to merge ".pyc" files -- 
> byte-compiled Python.  As far as I can tell, the only difference between the 
> i386 and x86_64 versions of .pyc files is a timestamp.  So, adding in a 
> "switch" for "*.pyc" is quite simple.

There is no such thing as a merged ".pyc" file.  pyc's are architecture 
independent.  With current pythons (certainly from 2.6 on) on OS X, any 
architecture-dependent code (32 vs 64, intel vs ppc) is isolated to C 
code that is linked into universal arch files (depending on configure 
options they can have from 1 to 4 architectures).

> (3) The "muniversal" group does all the fancy "arch" settings during the 
> MacPorts' "configure" stage, but there is no such stage for any Python group; 
> instead, everything happens during the MacPort's "build" phase.  Hence, the 
> "arch" flags must be set as part of the build.env, not the configure.env.  
> Hence, the "merger_build_env" array from muniversal is required.
> 
> (4) Setting just "YYYFLAGS=-mXX" (where YYY is, e.g., "C", "CXX", "LD", OBJC" 
> etc) via "merger_build_env " does not work, because (for example on my 
> system): In 32-bit mode during what is effectively the 'configure' stage of 
> setup.py, tests will be compiled as 32-bit, but linked without the "-m32" as 
> whatever the native bit-age of gcc is (for me, 64-bit).  This means that (for 
> me) the i386 compile will error out early on.  Hence, integrating the "-mXX" 
> flag into CC, CXX, and F90 is required (in order for the -mXX flag to be 
> present during testing as well as compiling).

Multi-architecture builds of python on OS X depend on the universal 
features in the Apple-supplied gcc's (currently 4.0 for 10.4/10.5/10.6 
and 4.2 for 10.6).  It would be a *major* undertaking to redo universal 
support to use a vanilla gcc without that support.  Further, python 
Distutils goes to some lengths to try to ensure that 3rd-party Python 
add-ons (distributions) with C extension modules are compiled and linked 
with the same compiler and compatible options (for example, -arch(s), 
SDK, MACOSX_DEPLOYMENT_TARGET) as python itself was.

Also I see that the OS X installer provided by the numpy project appears 
to be 32-bit (i386/ppc) only and depends on the python.org Python 2.6.  
Do you know whether they or anyone else has tried a mixed 32-/64-bit 
universal build?  It can be tricky to catch all the corner cases if 
there is a lot of C code involved which I assume is the case with numpy.

Good luck!

-- 
 Ned Deily,
 nad at acm.org