On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth dholth@gmail.com wrote:
That would make sense. Can you come up with code to detect that a newly compiled extension is universal, and that a Python is?
It looks like distutils.util.get_platform() now does the right thing for knowing what the currently running pyton is (see Ronald's message)
For determining the status of a newly compiled extension, I usually simple run the "file" command line utility on it:
$ file python python: Mach-O universal binary with 2 architectures python (for architecture ppc): Mach-O executable ppc python (for architecture i386): Mach-O executable i386
(works for *.so, too...)
that could easily be parsed out, but we would still want to know the deployment target, which maybe you could get by parsing otool output:
$ otool -L python python (architecture ppc): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) python (architecture i386): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)
(compatibility version of libSystem???)
But I imagine there is a cleaner way -- Ronald??
-Chris
On 4 Jun, 2013, at 18:35, Chris Barker - NOAA Federal chris.barker@noaa.gov wrote:
On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth dholth@gmail.com wrote:
That would make sense. Can you come up with code to detect that a newly compiled extension is universal, and that a Python is?
It looks like distutils.util.get_platform() now does the right thing for knowing what the currently running pyton is (see Ronald's message)
Correct. Barring installation errors, such as with some older releases of OSX, distutils.util.get_platform() already returns the correct information (both the supported architectures and the deployment target).
For determining the status of a newly compiled extension, I usually simple run the "file" command line utility on it:
$ file python python: Mach-O universal binary with 2 architectures python (for architecture ppc): Mach-O executable ppc python (for architecture i386): Mach-O executable i386
(works for *.so, too...)
that could easily be parsed out, but we would still want to know the deployment target, which maybe you could get by parsing otool output:
$ otool -L python python (architecture ppc): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) python (architecture i386): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)
(compatibility version of libSystem???)
But I imagine there is a cleaner way -- Ronald??
The output of 'otool -l' lists (amongst others) the value of LC_VERSION_MIN_MACOSX which is the deployment target.
Both can also be found using macholib ;-)
Ronald
On Tue, Jun 4, 2013 at 12:55 PM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 4 Jun, 2013, at 18:35, Chris Barker - NOAA Federal chris.barker@noaa.gov wrote:
On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth dholth@gmail.com wrote:
That would make sense. Can you come up with code to detect that a newly compiled extension is universal, and that a Python is?
It looks like distutils.util.get_platform() now does the right thing for knowing what the currently running pyton is (see Ronald's message)
Correct. Barring installation errors, such as with some older releases of OSX, distutils.util.get_platform() already returns the correct information (both the supported architectures and the deployment target).
For determining the status of a newly compiled extension, I usually simple run the "file" command line utility on it:
$ file python python: Mach-O universal binary with 2 architectures python (for architecture ppc): Mach-O executable ppc python (for architecture i386): Mach-O executable i386
(works for *.so, too...)
that could easily be parsed out, but we would still want to know the deployment target, which maybe you could get by parsing otool output:
$ otool -L python python (architecture ppc): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) python (architecture i386): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)
(compatibility version of libSystem???)
But I imagine there is a cleaner way -- Ronald??
The output of 'otool -l' lists (amongst others) the value of LC_VERSION_MIN_MACOSX which is the deployment target.
Both can also be found using macholib ;-)
Ronald
FYI pip (the development version that supports wheel) uses https://github.com/pypa/pip/blob/develop/pip/pep425tags.py to discover which tags it will consider. The tags are listed in order of most- to least-preferred; a file with a tag nearer the beginning of the list will be preferred when there is more than one choice for a particular version of a distribution.
On Tue, Jun 4, 2013 at 9:55 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
$ otool -L python python (architecture ppc): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) python (architecture i386): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)
(compatibility version of libSystem???)
But I imagine there is a cleaner way -- Ronald??
The output of 'otool -l' lists (amongst others) the value of LC_VERSION_MIN_MACOSX which is the deployment target.
I don't see that on my machine -- is that "l", a lower-case "el'?
Both can also be found using macholib ;-)
probably best not to add another dependency.
But I've lot track on why we'd need this -- presumably the wheel builder would know what it built, and could supply the proper meta-data, and that would be that.
-Chris
On 4 Jun, 2013, at 23:53, Chris Barker - NOAA Federal chris.barker@noaa.gov wrote:
On Tue, Jun 4, 2013 at 9:55 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
$ otool -L python python (architecture ppc): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) python (architecture i386): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)
(compatibility version of libSystem???)
But I imagine there is a cleaner way -- Ronald??
The output of 'otool -l' lists (amongst others) the value of LC_VERSION_MIN_MACOSX which is the deployment target.
I don't see that on my machine -- is that "l", a lower-case "el'?
The option or the LC_VERSION_MIN_MACOSX value? I'm running OSX 10.8, where both are available, but according to Google LC_VERSION_MIN_MACOSX was introduced in a 10.6 subrelease. Without that load command you cannot easily see what the deployment target is (the best way I find while writing would be a tool that checks library load commands and the list of symbols used with a to-be-maintained registry).
Both can also be found using macholib ;-)
probably best not to add another dependency.
But I've lot track on why we'd need this -- presumably the wheel builder would know what it built, and could supply the proper meta-data, and that would be that.
You don't need this, distutils (and hence setuptools) already knows this information and other build tools can also know this.
Ronald
-Chris
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
-
Chris Barker - NOAA Federal -
Daniel Holth -
Ronald Oussoren