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.
1) A non-critical off-by-one error in pythonw
2) A problem in the configure script that caused
builds with '--enable-framework --enable-universalsdk=/'
to fail on OSX 10.6.
(I asked the BDFL first, and he approved removing it. The last actual bugfix
to Tools/modulator was in 2001; since then all changes have been search-and-replace:
string methods, whitespace fixes, etc.)
- 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
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.
/usr/local by default. Users can still choose to install files into /usr/local, but by
default we'll only install files in /Library/Framework/Python.framework and
/Applications/Python X.Y/
to that README file with some explanation.
* Be more strict in the configure script: complain loudly when the user has
specified invalid combinations of OSX-specific configure arguments.
The error message refers to the Mac/README file for more information.
-Wall -Wstrict-prototypes -Werror" in both --with-pydebug mode and --without.
There's still a batch of non-prototype warnings in Xlib.h that I don't know how
to fix.
* Remove last traces of "MacPython"
* Add options to build different flavors of the installer
(still defaulting to a 2-way universal build that
runs on OSX 10.3)
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.
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).
by purging bindings to OSA's debug API's. Those APIs we're completely
unsupported on OSX 10.4 and are no longer available on OSX 10.5.
Note that this patches a generated file. This is somewhat acceptable because
regenerating the file is non-trivial and wouldn't use system headers anyway.
This adds a new key definition for OSX, which is slightly different from the
classic mac definition.
Also add NEWS item for a couple of bugfixes I added recently.
without causing problems for anyone that is on a case-insensitive filesystem).
Setup.py tries to compile the MacOS extension from MacOSmodule.c, while the
actual file is named macosmodule.c. This is no problem on the (default)
case-insensitive filesystem, but doesn't work on case-sensitive filesystems.
way the resulting binaries have a better change of running on 10.3.
This patch also updates the search logic for sleepycat db3/4, without this
patch you cannot use a sleepycat build with a non-standard prefix; with this
you can (at least on OSX) if you add the prefix to CPPFLAGS/LDFLAGS at
configure-time. This change is needed to build the binary installer for OSX.
sys.exutable that isn't usuable on an #!-line. That results in generated
applets that don't actually work. Work around this problem by resetting
sys.executable.
* argvemulator.py didn't work on intel macs. This patch fixes this
(bug #1491468)
with --enable-framework
* Also for --enable-framework: allow users to use --prefix to specify
the location of the compatibility symlinks (such as /usr/local/bin/python)
- Some small bugfixes for the IDLE.app wrapper
- Tweaks to build-installer to ensure that python gets build in the right way,
including sqlite3.
- Updated readme files
This patches a file that is generated by bgen, however the code is now the
same as a current copy of bgen would generate. Without this patch most types
in the Carbon.CF module are unusable.
I haven't managed to coax bgen into generating a complete copy of _CFmodule.c
yet :-(, hence the manual patching.
* Don't use xcodebuild for building PythonLauncher, but use a normal unix
makefile. This makes it a lot easier to use the same build flags as for the
rest of python (e.g. make a universal version of python launcher)
* Convert the mac makefile-s to makefile.in-s and use configure to set makefile
variables instead of forwarding them as command-line arguments
* Add a C version of pythonw, that we you can use '#!/usr/local/bin/pythonw'
* Build IDLE.app using bundlebuilder instead of BuildApplet, that will allow
easier modification of the bundle contents later on.
this file (the source) must be fixed.
Why isn't there a comment at the top saying the file is generated and
why are both the source and generated file checked in? Bootstrap problem?
Will backport.
Turns out patch #1035255 was incomplete, it only patched _Filemodule.c
and not filesupport.py. So regenerating caused as_pathname() to go into
an infinite loop.
the MACOSX_DEPLOYMENT_TARGET environment variable to 10.3 when calling the
loader. And we do this with "env" because distutils apparently doesn't
understand environment variable assignments before command names.
needs to run it in the Makefile).
After installing a newer framework Python the apple-installed Python can
no longer build extension modules, because they will inadvertantly be linked
against the newer framework. This script modifies lib/config/Makefile so
it will link extensions with "-undefined dynamic_lookup", which forestalls
this problem.
Will backport to 2.4 and 2.3.
(Contributed by Bob Ippolito.)
This patch trims down the Python core on Darwin by making it
independent of CoreFoundation and CoreServices. It does this by:
Changed linker flags in configure/configure.in
Removed the unused PyMac_GetAppletScriptFile
Moved the implementation of PyMac_StrError to the MacOS module
Moved the implementation of PyMac_GetFullPathname to the
Carbon.File module
Ronald Oussoren
Mark Dickinson
Benjamin Peterson
Andrew M. Kuchling
Georg Brandl
Jeffrey Yasskin
Gregory P. Smith
Christian Heimes
Tim Peters
Thomas Heller
Neal Norwitz
Martin v. Löwis
Fred Drake
Jack Jansen
Brett Cannon
Raymond Hettinger