summaryrefslogtreecommitdiffstats
path: root/Mac/Makefile.in
Commit message (Collapse)AuthorAgeFilesLines
* Fix for issue #7998: pythonw didn't work when --with-framework-name wasRonald Oussoren2010-03-071-1/+1
| | | | specified
* - Issue #7658: Ensure that the new pythonw executable works on OSX 10.4Ronald Oussoren2010-01-171-0/+1
| | | | | | | | | | | | - Issue #7714: Use ``gcc -dumpversion`` to detect the version of GCC on MacOSX. - Make configure look for util.h as well as libutil.h. The former is the header file that on OSX contains the defition of openpty. (Needed to compile for OSX 10.4 on OSX 10.6) - Use the correct definition of CC to compile the pythonw executable
* Issue #6834: replace the implementation for the 'python' and 'pythonw' ↵Ronald Oussoren2009-12-241-51/+13
| | | | | | | | | | | | | | | | | executables on OSX. The previous implementation used execv(2) to run the real interpreter, which means that you cannot use the arch(1) tool to select the architecture you want to use for a universal build because that only affects the python/pythonw wrapper and not the actual interpreter. The new version uses posix_spawnv with a number of OSX-specific options that ensure that the real interpreter is started using the same CPU architecture as the wrapper, and that means that 'arch -ppc python' now actually works. I've also changed the way that the wrapper looks for the framework: it is now linked to the framework rather than hardcoding the framework path. This should make it easier to provide pythonw support in tools like virtualenv.
* Remove some old MacPython files that are no longer relevant.Ronald Oussoren2009-05-191-9/+1
|
* Fixes issue 5270Ronald Oussoren2009-03-301-0/+7
|
* Fix build issue on OSX 10.4, somehow this wasn't committed before.Ronald Oussoren2008-07-221-2/+2
|
* issue #3199: Fix typo in Mac/Makefile.inMark Dickinson2008-06-251-1/+1
|
* MacOS X: Enable 4-way universal buildsRonald Oussoren2008-06-051-6/+60
| | | | | | | | | | | | | | | | | | This patch adds a new configure argument on OSX: --with-universal-archs=[32-bit|64-bit|all] When used with the --enable-universalsdk option this controls which CPU architectures are includes in the framework. The default is 32-bit, meaning i386 and ppc. The most useful alternative is 'all', which includes all 4 CPU architectures supported by MacOS X (i386, ppc, x86_64 and ppc64). This includes limited support for the Carbon bindings in 64-bit mode as well, limited because (a) I haven't done extensive testing and (b) a large portion of the Carbon API's aren't available in 64-bit mode anyway. I've also duplicated a feature of Apple's build of python: setting the environment variable 'ARCHFLAGS' controls the '-arch' flags used for building extensions using distutils.
* Fix for issue #2573: Can't change the framework name on OS X buildsRonald Oussoren2008-05-021-4/+6
| | | | | | | This introduces a new configure option: --with-framework-name=NAME (defaulting to 'Python'). This allows you to install several copies of the Python framework with different names (such as a normal build and a debug build).
* Tweak Mac/Makefile in to ensure that pythonw gets rebuild when the major versionRonald Oussoren2006-09-171-1/+4
| | | | of python changes (2.5 -> 2.6). Bug #1552935.
* Use configure to substitute the correct prefix instead of hardcodingRonald Oussoren2006-06-111-1/+1
|
* Move Mac/OSX/* one level upRonald Oussoren2006-06-071-0/+251
generated by cgit v0.12 at 2025-02-27 20:29:08 (GMT)