This flag adds specific support for the -arch and -isysroot flags of GCC 
on MacOSX 10.4 or later.

The patch consists of two parts:

1) Remove these flags (and their arguments) from the base CFLAGS/
LDFLAGS when compiling extensions on OSX 10.3 or earlier because GCC 
doesn't support those arguments in the version of GCC that is shipped 
what the version of the OS.

2) Strip -arch and -isysroot (again including their arguments) from the 
base CFLAGS/LDFLAGS when the user has specified new values for them 
in the extra_compile_args and extra_link args.

The second part is needed because -isysroot can only be specified once 
and the -arch option is incremental, without this patch you cannot 
compile using a different SDK or for fewer architectures.

A reason for wanting to do the latter is software like psyco that is only 
fully supported on one of the architectures for OSX.

Logged In: YES 
user_id=33168

I don't see any obvious problems with the patch.  I have
some nits though:

 * This is pretty complex: int(os.uname()[2].split('.')[0])
   I would prefer if it was broken up and use local
variables to explain better what's going on (or at least a
comment that shows the expected format).
  - same with '.'.join(m.group(1).split('.')[:2])

 * Remove double blank lines at first line of patch in
util.py and the last 3 lines (the pass is not needed).

 * unixcompiler.py, use True/False instead of 1/0.  I forget
what the compatibility of distutils is, but I see other uses
of True and False

   - same comment about getting the kernel with a complex expr

   - I prefer index instead of idx (I don't like abbrevs,
particularly for foreign speakers)

Instead of: 
+        if '-arch' in cc_args:
+            stripArch = 1

just set it:  stripArch = '-arch' in cc_args

Same for stripSysroot

Logged In: YES 
user_id=580910

I've updated the patch with the stylistic changes you've requested.

BTW. I don't think idx is confusing, although I suppose it helps that the Dutch 
term for index is index :-)

BTW. Distutils.archive_util claims it should be kept 2.1 compatible, although I 
don't know if that request covers all of distutils. PEP 291 doesn't mention 
distutils.

Logged In: YES 
user_id=33168

Heh, I never realized you were Dutch. :-)

It took some time to find.  I thought distutils was in 291,
but as you point out there's nothing there now.  So after
finding some references to distutils and 291, I did an svn
log on the PEP and sure enough:

r1982 | akuchling | 2005-03-20 12:47:01 -0800 (Sun, 20 Mar
2005) | 10 lines

After some discussion at the distutils sprint at PyCon 2005,
it seems that no one really wants to make a new standalone
release of Distutils. Given that, there's no reason for
Distutils code to preserve backward compatibility, so I am
removing the requirement for 2.1 compatibility.

I'm not sure if I'll have time to review this patch soon
(probably over a week).

Is this patch required to get Python working on x86 Macs?  I
know there were a couple of bug reports about x86 Mac.  If
so or you want more testing, it would be better to check
this in sooner rather than later.  I doubt I will find more
on a second review of this patch (and I try to review all
checkins).  So if you want and think it's appropriate go
ahead and check in.  If you want more review, you can try to
wait for me or solicit input from python-dev.

Logged In: YES 
user_id=580910

This patch isn't strictly necessary to get python going on x86, that should 
work just fine as it is right now. The trunk builds fine for me, except for libffi 
but that's a know issue and high on my list.

The primary reason for this patch is to be able to build a universal binary 
distribution of python on 10.4 and then use the result on 10.3. Without this 
patch you won't be able to build extensions on 10.3 in that scenario because 
distutils will use some compiler flags that aren't valid for the compiler that 
ships with 10.3.

I'll check this in.

Logged In: YES 
user_id=580910

Checked in as revision 46104