Commit Graph

16 Commits

Author SHA1 Message Date
Ned Deily 22f63b50e3 Issue #11217: For 64-bit/32-bit Mac OS X universal framework builds,
ensure "make install" creates symlinks in --prefix bin for the "-32"
files in the framework bin directory like the installer does.
2011-05-28 05:56:14 -07:00
Ronald Oussoren 0969c67bf5 Fix for issue 9392: without this patch a framework build will not install
2to3-2.7, while a versioned copy is installed of other tools and a versioned copy of2to3 is installed by python 2.6, 3.1 and the 3.2 alpha.
2010-07-29 13:18:19 +00:00
Ronald Oussoren 01d149fc1f Fix for issue #3646: with this patch it is possible to do a
framework install of Python in your home directory (on OSX):

   $ configure --enable-framework=${HOME}/Library/Frameworks
   $ make && make install

Without this patch the framework would get installed just fine,
but 'make install' would try to install the application bundles
and command-line tools outside the user's home, which doesn't work
for non-admin users (and is bad form anyway).
2010-04-30 11:20:14 +00:00
Ronald Oussoren 1bf02022fe The PythonLauncher change is needed due
to changes in how the BASECFLAGS and CFLAGS
variables get filled by configure.

The Mac/Makefile.in change ensures that
pythonw gets build with the rigth deployment
targets.
2010-04-20 08:53:12 +00:00
Ronald Oussoren 2a4ab81633 Fix for issue #7998: pythonw didn't work when --with-framework-name was
specified
2010-03-07 09:04:06 +00:00
Ronald Oussoren a55af9a9db - Issue #7658: Ensure that the new pythonw executable works on OSX 10.4
- 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
2010-01-17 16:25:57 +00:00
Ronald Oussoren 92919a66d2 Issue #6834: replace the implementation for the 'python' and 'pythonw' 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.
2009-12-24 13:30:58 +00:00
Ronald Oussoren 364b22183c Remove some old MacPython files that are no longer relevant. 2009-05-19 20:12:17 +00:00
Ronald Oussoren 354bb5ca67 Fixes issue 5270 2009-03-30 19:56:25 +00:00
Ronald Oussoren 5aa0b4d766 Fix build issue on OSX 10.4, somehow this wasn't committed before. 2008-07-22 07:06:33 +00:00
Mark Dickinson 1b6c4c80a3 issue #3199: Fix typo in Mac/Makefile.in 2008-06-25 15:29:32 +00:00
Ronald Oussoren 5640ce2f1e MacOS X: Enable 4-way universal builds
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.
2008-06-05 12:58:24 +00:00
Ronald Oussoren 580c7fec67 Fix for issue #2573: Can't change the framework name on OS X builds
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).
2008-05-02 19:45:11 +00:00
Ronald Oussoren a6790f1aab Tweak Mac/Makefile in to ensure that pythonw gets rebuild when the major version
of python changes (2.5 -> 2.6). Bug #1552935.
2006-09-17 19:23:27 +00:00
Ronald Oussoren 4fbb080bc1 Use configure to substitute the correct prefix instead of hardcoding 2006-06-11 20:23:29 +00:00
Ronald Oussoren 32f5d8f1b1 Move Mac/OSX/* one level up 2006-06-07 19:02:03 +00:00