Repository navigation
MacOSX: distutils support for -arch and -isysroot flags #43354
Description
| BPO | 1488098 |
|---|---|
| Nosy | @ronaldoussoren |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2006-05-23.12:30:09.000>
created_at = <Date 2006-05-13.21:13:55.000>
labels = ['library']
title = 'MacOSX: distutils support for -arch and -isysroot flags'
updated_at = <Date 2006-05-23.12:30:09.000>
user = 'https://github.com/ronaldoussoren'bugs.python.org fields:
activity = <Date 2006-05-23.12:30:09.000>
actor = 'ronaldoussoren'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Distutils']
creation = <Date 2006-05-13.21:13:55.000>
creator = 'ronaldoussoren'
dependencies = []
files = ['7246', '7247']
hgrepos = []
issue_num = 1488098
keywords = ['patch']
message_count = 6.0
messages = ['50238', '50239', '50240', '50241', '50242', '50243']
nosy_count = 2.0
nosy_names = ['nnorwitz', 'ronaldoussoren']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1488098'
versions = ['Python 2.5']
Activity
ronaldoussoren commentedon May 13, 2006
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:
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.
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.
nnorwitz commentedon May 15, 2006
Logged In: YES
user_id=33168
I don't see any obvious problems with the patch. I have
some nits though:
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).
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
ronaldoussoren commentedon May 19, 2006
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.
nnorwitz commentedon May 23, 2006
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.
ronaldoussoren commentedon May 23, 2006
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.
ronaldoussoren commentedon May 23, 2006
Logged In: YES
user_id=580910
Checked in as revision 46104