Mirror
/
cpython
mirror of https://github.com/python/cpython
4
1
Fork 0
Code Issues Releases Wiki Activity
cpython/Mac/Makefile.in

300 lines
10 KiB
Makefile
Raw Normal View History

Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
# This file can be invoked from the various frameworkinstall... targets in the
# main Makefile. The next couple of variables are overridden on the
# commandline in that case.
VERSION=@VERSION@
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
builddir = ..
srcdir=@srcdir@
Use configure to substitute the correct prefix instead of hardcoding
2006-06-11 17:23:29 -03:00
prefix=@prefix@
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
LIBDEST=$(prefix)/lib/python$(VERSION)
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
RUNSHARED=@RUNSHARED@
BUILDEXE=@BUILDEXEEXT@
BUILDPYTHON=$(builddir)/python$(BUILDEXE)
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
DESTDIR=
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
LDFLAGS=@LDFLAGS@
* Ensure that "make altinstall" works when the tree was configured 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)
2006-06-06 16:50:24 -03:00
FRAMEWORKUNIXTOOLSPREFIX=@FRAMEWORKUNIXTOOLSPREFIX@
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 16:45:11 -03:00
PYTHONFRAMEWORK=@PYTHONFRAMEWORK@
Fixes issue 5270
2009-03-30 16:56:25 -03:00
PYTHONFRAMEWORKIDENTIFIER=@PYTHONFRAMEWORKIDENTIFIER@
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 09:30:58 -04:00
LIPO_32BIT_FLAGS=@LIPO_32BIT_FLAGS@
- 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 12:25:57 -04:00
CC=@CC@
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 05:53:12 -03:00
MACOSX_DEPLOYMENT_TARGET=@CONFIGURE_MACOSX_DEPLOYMENT_TARGET@
export MACOSX_DEPLOYMENT_TARGET
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
# These are normally glimpsed from the previous set
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
bindir=$(prefix)/bin
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 08:20:14 -03:00
PYTHONAPPSDIR=@FRAMEWORKINSTALLAPPSPREFIX@/$(PYTHONFRAMEWORK) $(VERSION)
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
APPINSTALLDIR=$(prefix)/Resources/Python.app
# Variables for installing the "normal" unix binaries
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 16:45:11 -03:00
INSTALLED_PYTHONAPP=$(APPINSTALLDIR)/Contents/MacOS/$(PYTHONFRAMEWORK)
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
# Items more-or-less copied from the main Makefile
DIRMODE=755
FILEMODE=644
INSTALL=@INSTALL@
INSTALL_SYMLINK=ln -fsn
INSTALL_PROGRAM=@INSTALL_PROGRAM@
INSTALL_SCRIPT= @INSTALL_SCRIPT@
INSTALL_DATA=@INSTALL_DATA@
LN=@LN@
STRIPFLAG=-s
CPMAC=/Developer/Tools/CpMac
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
APPTEMPLATE=$(srcdir)/Resources/app
Remove some old MacPython files that are no longer relevant.
2009-05-19 17:12:17 -03:00
APPSUBDIRS=MacOS Resources
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
CACHERSRC=$(srcdir)/scripts/cachersrc.py
compileall=$(srcdir)/../Lib/compileall.py
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
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 09:30:58 -04:00
installapps: install_Python install_pythonw install_BuildApplet install_PythonLauncher \
install_IDLE checkapplepython install_versionedtools
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 09:58:24 -03:00
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
install_pythonw: pythonw
$(INSTALL_PROGRAM) $(STRIPFLAG) pythonw "$(DESTDIR)$(prefix)/bin/pythonw$(VERSION)"
$(INSTALL_PROGRAM) $(STRIPFLAG) pythonw "$(DESTDIR)$(prefix)/bin/python$(VERSION)"
Issue #12627: Implement PEP 394 for OS X framework builds. OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7. The changes here add a hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets. This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH. Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.
2012-02-18 21:19:12 -04:00
ln -sf python$(VERSION) "$(DESTDIR)$(prefix)/bin/python2"
ln -sf python2 "$(DESTDIR)$(prefix)/bin/python"
ln -sf pythonw$(VERSION) "$(DESTDIR)$(prefix)/bin/pythonw2"
ln -sf pythonw2 "$(DESTDIR)$(prefix)/bin/pythonw"
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 09:30:58 -04:00
ifneq ($(LIPO_32BIT_FLAGS),)
lipo $(LIPO_32BIT_FLAGS) -output $(DESTDIR)$(prefix)/bin/python$(VERSION)-32 pythonw
lipo $(LIPO_32BIT_FLAGS) -output $(DESTDIR)$(prefix)/bin/pythonw$(VERSION)-32 pythonw
Issue #12627: Implement PEP 394 for OS X framework builds. OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7. The changes here add a hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets. This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH. Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.
2012-02-18 21:19:12 -04:00
ln -sf python$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/python2-32"
ln -sf python2-32 "$(DESTDIR)$(prefix)/bin/python-32"
ln -sf pythonw$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/pythonw2-32"
ln -sf pythonw2-32 "$(DESTDIR)$(prefix)/bin/pythonw-32"
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 09:30:58 -04:00
endif
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 09:58:24 -03:00
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
#
# Install unix tools in /usr/local/bin. These are just aliases for the
# actual installation inside the framework.
#
installunixtools:
* Ensure that "make altinstall" works when the tree was configured 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)
2006-06-06 16:50:24 -03:00
if [ ! -d "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin" ]; then \
$(INSTALL) -d -m $(DIRMODE) "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin" ;\
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
fi
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 10:18:19 -03:00
for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
Issue #12627: Implement PEP 394 for OS X framework builds. OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7. The changes here add a hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets. This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH. Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.
2012-02-18 21:19:12 -04:00
python2 pythonw2 idle2 \
pydoc2 python2-config smtpd2.py \
2to3-2 \
* Ensure that "make altinstall" works when the tree was configured 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)
2006-06-06 16:50:24 -03:00
python$(VERSION) pythonw$(VERSION) idle$(VERSION) \
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 10:18:19 -03:00
pydoc$(VERSION) python$(VERSION)-config smtpd$(VERSION).py \
2to3-$(VERSION) ;\
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
do \
* Ensure that "make altinstall" works when the tree was configured 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)
2006-06-06 16:50:24 -03:00
ln -fs "$(prefix)/bin/$${fn}" "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin/$${fn}" ;\
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
done
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 09:56:14 -03:00
ifneq ($(LIPO_32BIT_FLAGS),)
for fn in python-32 pythonw-32 \
Issue #12627: Implement PEP 394 for OS X framework builds. OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7. The changes here add a hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets. This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH. Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.
2012-02-18 21:19:12 -04:00
python2-32 pythonw2-32 \
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 09:56:14 -03:00
python$(VERSION)-32 pythonw$(VERSION)-32 ;\
do \
ln -fs "$(prefix)/bin/$${fn}" "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin/$${fn}" ;\
done
endif
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
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 09:58:24 -03:00
* Ensure that "make altinstall" works when the tree was configured 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)
2006-06-06 16:50:24 -03:00
#
# Like installunixtools, but only install links to the versioned binaries.
#
altinstallunixtools:
if [ ! -d "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin" ]; then \
$(INSTALL) -d -m $(DIRMODE) "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin" ;\
fi
for fn in python$(VERSION) pythonw$(VERSION) idle$(VERSION) \
issue #3199: Fix typo in Mac/Makefile.in
2008-06-25 12:29:32 -03:00
pydoc$(VERSION) python$(VERSION)-config smtpd$(VERSION).py ;\
* Ensure that "make altinstall" works when the tree was configured 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)
2006-06-06 16:50:24 -03:00
do \
ln -fs "$(prefix)/bin/$${fn}" "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin/$${fn}" ;\
done
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 09:56:14 -03:00
ifneq ($(LIPO_32BIT_FLAGS),)
for fn in python$(VERSION)-32 pythonw$(VERSION)-32 ;\
do \
ln -fs "$(prefix)/bin/$${fn}" "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin/$${fn}" ;\
done
endif
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 10:18:19 -03:00
ln -fs "$(prefix)/bin/2to3-$(VERSION)" "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin/2to3-$(VERSION)" ;\
* Ensure that "make altinstall" works when the tree was configured 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)
2006-06-06 16:50:24 -03:00
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
# By default most tools are installed without a version in their basename, to
# make it easier to install (and use) several python versions side-by-side move
# the tools to a version-specific name and add the non-versioned name as an
# alias.
install_versionedtools:
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 09:58:24 -03:00
for fn in idle pydoc ;\
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
do \
Avoid creating a mess when installing a framework for the second time.
2006-05-23 08:04:24 -03:00
if [ -h "$(DESTDIR)$(prefix)/bin/$${fn}" ]; then \
continue ;\
fi ;\
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
mv "$(DESTDIR)$(prefix)/bin/$${fn}" "$(DESTDIR)$(prefix)/bin/$${fn}$(VERSION)" ;\
Issue #12627: Implement PEP 394 for OS X framework builds. OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7. The changes here add a hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets. This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH. Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.
2012-02-18 21:19:12 -04:00
ln -sf "$${fn}$(VERSION)" "$(DESTDIR)$(prefix)/bin/$${fn}2" ;\
ln -sf "$${fn}2" "$(DESTDIR)$(prefix)/bin/$${fn}" ;\
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
done
Avoid creating a mess when installing a framework for the second time.
2006-05-23 08:04:24 -03:00
if [ ! -h "$(DESTDIR)$(prefix)/bin/smtpd.py" ]; then \
mv "$(DESTDIR)$(prefix)/bin/smtpd.py" "$(DESTDIR)$(prefix)/bin/smtpd$(VERSION).py" ;\
Issue #12627: Implement PEP 394 for OS X framework builds. OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7. The changes here add a hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets. This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH. Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.
2012-02-18 21:19:12 -04:00
ln -sf "smtpd$(VERSION).py" "$(DESTDIR)$(prefix)/bin/smtpd2.py" ;\
ln -sf "smtpd2.py" "$(DESTDIR)$(prefix)/bin/smtpd.py" ;\
Avoid creating a mess when installing a framework for the second time.
2006-05-23 08:04:24 -03:00
fi
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 10:18:19 -03:00
if [ ! -h "$(DESTDIR)$(prefix)/bin/2to3" ]; then \
mv "$(DESTDIR)$(prefix)/bin/2to3" "$(DESTDIR)$(prefix)/bin/2to3-$(VERSION)" ;\
Issue #12627: Implement PEP 394 for OS X framework builds. OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7. The changes here add a hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets. This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH. Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.
2012-02-18 21:19:12 -04:00
ln -sf "2to3-$(VERSION)" "$(DESTDIR)$(prefix)/bin/2to3-2" ;\
ln -sf "2to3-2" "$(DESTDIR)$(prefix)/bin/2to3" ;\
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 10:18:19 -03:00
fi
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
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 16:23:27 -03:00
pythonw: $(srcdir)/Tools/pythonw.c Makefile
Fix for issue #7998: pythonw didn't work when --with-framework-name was specified
2010-03-07 05:04:06 -04:00
$(CC) $(LDFLAGS) -DPYTHONFRAMEWORK='"$(PYTHONFRAMEWORK)"' -o $@ $(srcdir)/Tools/pythonw.c -I.. -I$(srcdir)/../Include ../$(PYTHONFRAMEWORK).framework/Versions/$(VERSION)/$(PYTHONFRAMEWORK)
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
install_PythonLauncher:
cd PythonLauncher && make install DESTDIR=$(DESTDIR)
install_Python:
@for i in "$(PYTHONAPPSDIR)" "$(APPINSTALLDIR)" "$(APPINSTALLDIR)/Contents"; do \
if test ! -d "$(DESTDIR)$$i"; then \
echo "Creating directory $(DESTDIR)$$i"; \
$(INSTALL) -d -m $(DIRMODE) "$(DESTDIR)$$i"; \
fi;\
done
@for i in $(APPSUBDIRS); do \
if test ! -d "$(DESTDIR)$(APPINSTALLDIR)/Contents/$$i"; then \
echo "Creating directory $(DESTDIR)$(APPINSTALLDIR)/Contents/$$i"; \
$(INSTALL) -d -m $(DIRMODE) "$(DESTDIR)$(APPINSTALLDIR)/Contents/$$i"; \
else true; \
fi; \
done
@for d in . $(APPSUBDIRS); \
do \
a=$(APPTEMPLATE)/$$d; \
if test ! -d $$a; then continue; else true; fi; \
b="$(DESTDIR)$(APPINSTALLDIR)/Contents/$$d"; \
for i in $$a/*; \
do \
case $$i in \
*CVS) ;; \
*.svn) ;; \
*.py[co]) ;; \
*.orig) ;; \
*~) ;; \
*idx) \
echo $(CPMAC) "$$i" $$b; \
$(CPMAC) "$$i" "$$b"; \
;; \
*) \
if test -d $$i; then continue; fi; \
if test -x $$i; then \
echo $(INSTALL_SCRIPT) "$$i" "$$b"; \
$(INSTALL_SCRIPT) "$$i" "$$b"; \
else \
echo $(INSTALL_DATA) "$$i" "$$b"; \
$(INSTALL_DATA) "$$i" "$$b"; \
fi;; \
esac; \
done; \
done
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 16:45:11 -03:00
$(INSTALL_PROGRAM) $(STRIPFLAG) $(BUILDPYTHON) "$(DESTDIR)$(APPINSTALLDIR)/Contents/MacOS/$(PYTHONFRAMEWORK)"
Fixes issue 5270
2009-03-30 16:56:25 -03:00
sed -e "s!%bundleid%!$(PYTHONFRAMEWORKIDENTIFIER)!g" \
-e "s!%version%!`$(RUNSHARED) $(BUILDPYTHON) \
-c 'import platform; print(platform.python_version())'`!g" \
< "$(DESTDIR)$(APPINSTALLDIR)/Contents/Info.plist.in" \
> "$(DESTDIR)$(APPINSTALLDIR)/Contents/Info.plist"
rm "$(DESTDIR)$(APPINSTALLDIR)/Contents/Info.plist.in"
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
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 09:58:24 -03:00
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
install_IDLE:
cd IDLE && make install
install_BuildApplet:
Fix build issue on OSX 10.4, somehow this wasn't committed before.
2008-07-22 04:06:33 -03:00
$(RUNSHARED) @ARCH_RUN_32BIT@ $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
--destroot "$(DESTDIR)" \
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 09:30:58 -04:00
--python=$(prefix)/Resources/Python.app/Contents/MacOS/Python \
Fix some minor issues with the generated application bundles on MacOSX
2006-05-18 06:04:15 -03:00
--output "$(DESTDIR)$(PYTHONAPPSDIR)/Build Applet.app" \
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
$(srcdir)/scripts/BuildApplet.py
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 09:30:58 -04:00
ifneq ($(LIPO_32BIT_FLAGS),)
rm "$(DESTDIR)$(PYTHONAPPSDIR)/Build Applet.app/Contents/MacOS/Python"
lipo $(LIPO_32BIT_FLAGS) -output "$(DESTDIR)$(PYTHONAPPSDIR)/Build Applet.app/Contents/MacOS/Python" $(BUILDPYTHON)
endif
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
MACLIBDEST=$(LIBDEST)/plat-mac
MACTOOLSDEST=$(prefix)/Mac/Tools
MACTOOLSSRC=$(srcdir)/Mac/Tools
MACTOOLSSUBDIRS=IDE
installmacsubtree:
@for i in $(MACTOOLSDEST); \
do \
if test ! -d $(DESTDIR)$$i; then \
echo "Creating directory $(DESTDIR)$$i"; \
$(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \
else true; \
fi; \
done
@for d in $(MACTOOLSSUBDIRS); \
do \
a=$(MACTOOLSSRC)/$$d; \
if test ! -d $$a; then continue; else true; fi; \
b=$(DESTDIR)$(MACTOOLSDEST)/$$d; \
if test ! -d $$b; then \
echo "Creating directory $$b"; \
$(INSTALL) -d -m $(DIRMODE) $$b; \
else true; \
fi; \
done
@for d in $(MACTOOLSSUBDIRS); \
do \
a=$(MACTOOLSSRC)/$$d; \
if test ! -d $$a; then continue; else true; fi; \
b=$(DESTDIR)$(MACTOOLSDEST)/$$d; \
for i in $$a/*; \
do \
case $$i in \
*CVS) ;; \
*.svn) ;; \
*.py[co]) ;; \
*.orig) ;; \
*~) ;; \
*.rsrc) \
echo $(CPMAC) $$i $$b ; \
$(CPMAC) $$i $$b ; \
;; \
*) \
if test -d $$i; then continue; fi; \
if test -x $$i; then \
echo $(INSTALL_SCRIPT) $$i $$b; \
$(INSTALL_SCRIPT) $$i $$b; \
else \
echo $(INSTALL_DATA) $$i $$b; \
$(INSTALL_DATA) $$i $$b; \
fi;; \
esac; \
done; \
done
Fix build issue on OSX 10.4, somehow this wasn't committed before.
2008-07-22 04:06:33 -03:00
$(RUNSHARED) @ARCH_RUN_32BIT@ $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST)
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
$(RUNSHARED) $(BUILDPYTHON) -Wi -tt $(compileall) -d $(MACTOOLSDEST) -x badsyntax $(DESTDIR)$(MACTOOLSDEST)
$(RUNSHARED) $(BUILDPYTHON) -O -Wi -tt $(compileall) -d $(MACTOOLSDEST) -x badsyntax $(DESTDIR)$(MACTOOLSDEST)
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
$(INSTALLED_PYTHONAPP): install_Python
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
installextras: $(srcdir)/Extras.ReadMe.txt $(srcdir)/Extras.install.py
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
$(INSTALL) -d "$(DESTDIR)$(PYTHONAPPSDIR)/Extras"
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
$(INSTALL) $(srcdir)/Extras.ReadMe.txt "$(DESTDIR)$(PYTHONAPPSDIR)/Extras/ReadMe.txt"
$(RUNSHARED) $(BUILDPYTHON) $(srcdir)/Extras.install.py $(srcdir)/../Demo \
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
"$(DESTDIR)$(PYTHONAPPSDIR)/Extras/Demo"
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
$(RUNSHARED) $(BUILDPYTHON) $(srcdir)/Extras.install.py $(srcdir)/Demo \
"$(DESTDIR)$(PYTHONAPPSDIR)/Extras/Demo.Mac"
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
checkapplepython: $(srcdir)/Tools/fixapplepython23.py
@if ! $(RUNSHARED) $(BUILDPYTHON) $(srcdir)/Tools/fixapplepython23.py -n; then \
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
echo "* WARNING: Apple-installed Python 2.3 will have trouble building extensions from now on."; \
Move Mac/OSX/* one level up
2006-06-07 16:02:03 -03:00
echo "* WARNING: Run $(srcdir)/Tools/fixapplepython23.py with \"sudo\" to fix this."; \
Rework the build system for osx applications: * 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.
2006-05-14 16:56:34 -03:00
fi
clean:
rm pythonw
cd PythonLauncher && make clean
cd IDLE && make clean
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 16:23:27 -03:00
Makefile: $(srcdir)/Makefile.in ../config.status
cd .. && CONFIG_FILES=Mac/Makefile CONFIG_HEADERS= $(SHELL) ./config.status