[Python-Dev] What does the "m" mean for the Mac OS X include folder?

[Barry Scott]

On 7 Mar 2011, at 01:46, Ned Deily wrote:

> In article <5AB965C9-7D5F-41B6-A5E9-2B881E92A782 at barrys-emacs.org>,
> Barry Scott <barry at barrys-emacs.org> wrote:
>> There is a break with convention for the include folder name:
>> 
>> /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/
>> 
>> What does the "m" mean?
> 
> The "m" means that the Python was configured and built with pymalloc.
> 
> This change was introduced by Issue9807 "deriving configuration 
> information for different builds with the same prefix" which is an 
> adjunct to PEP 3149 "ABI version tagged .so files".  As described in the 
> PEP, the idea is to allow the installation of multiple build variants on 
> one system, for instance, a set of debug shared libraries (with flag 
> "d") alongside the normal optimized libraries.  This was extended in 
> Issue9807 to cover the corresponding Include files.   On current Debian 
> installs of python3.2, for instance, one sees:
> 
> $ ls -ld /usr/include/python3.2*
> lrwxrwxrwx [...] /usr/include/python3.2 -> python3.2mu
> drwxr-xr-x [...] /usr/include/python3.2mu
> 
> ("u" means "wide-unicode".)
> 
> For OS X framework builds, the unversioned convenience link is not 
> created:
> 
> $ cd /Library/Frameworks/Python.framework/Versions/3.2
> $ ls -l
> lrwxr-xr-x [...] Headers@ -> include/python3.2m
> -r-xrwxr-x [...] Python*
> drwxrwxr-x [...] Resources/
> drwxrwxr-x [...] bin/
> drwxrwxr-x [...] include/
> drwxrwxr-x [...] lib/
> drwxrwxr-x [...] share/
> $ ls -ld ./include/python3.2*
> drwxrwxr-x [...] ./include/python3.2m/
> 
> Perhaps it should.  And the implications of the multiple build variants 
> feature for OS X frameworks build have probably not yet been fully 
> considered.  However, there are now multiple ways to find the proper 
> location of the include files and library files, both in 
> platform-independent and framework-specific (note the "Headers" link) 
> ways.  And they all seem to produce the correct results.
> 
> $ bin/python3.2
>>>> import sysconfig
>>>> sysconfig.get_path('include')
> '/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/p
> ython3.2m'
> ^D
> $ bin/python3-config --include
> -I/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/
> python3.2m 
> -I/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/
> python3.2m
> 
> (So good you get it twice in the same line.)
> 
> In some ways, this issue falls into a bit of a black hole.  For other 
> Unix-y platforms, the PSF (python.org) does not provide binaries or 
> installers so issues like installation locations are to some extent at 
> the discretion of the various distributors (Debian, Fedora, et al).  For 
> Mac OS X and Windows, the PSF also plays the role of binaries/installer 
> distributor so some things specific to those installers may need to be 
> documented outside of the standard Python documentation set (or properly 
> noted).
> 
> Feel free to open an issue if you feel something should be changed (code 
> or documentation).

Thanks for this full explanation.

I can use the Headers link and that will make it possible to do the same thing
for compiling against all versions from 2.4 to 3.2.

Barry