kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/lang/python27/Makefile

234 lines
7 KiB
Makefile
Raw Normal View History

python*: Revert shm_open workaround now it's fixed in mksandbox
2020-12-07 14:14:38 +01:00
# $NetBSD: Makefile,v 1.93 2020/12/07 13:14:38 nia Exp $
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
.include "dist.mk"
PKGNAME= python27-${PY_DISTVERSION}
lang/python27: backport vulnerability fixes from Gentoo Backport 3 vulnerability fixes from Python 3.6 using rebased patches from Gentoo. These are: bpo-39017 (CVE-2019-20907): infinite loop in tarfile.py bpo-39503 (CVE-2020-8492): ReDoS on AbstractBasicAuthHandler bpo-39603 (no CVE): header injection via HTTP method
2020-09-20 13:06:23 +02:00
PKGREVISION= 3
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
CATEGORIES= lang python
MAINTAINER= pkgsrc-users@NetBSD.org
Follow some redirects.
2017-09-03 10:53:04 +02:00
HOMEPAGE= https://www.python.org/
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
COMMENT= Interpreted, interactive, object-oriented programming language
LICENSE= python-software-foundation
Use the "cacert.pem" file from the "mozilla-rootcerts" package as an *extra* location to load CA certificates from in the "ssl" module. HTTPS requests to a site with a valid certificate now work out of the box (even without the "mozilla-rootcerts-openssl").
2016-02-06 12:25:09 +01:00
DEPENDS= mozilla-rootcerts>=1.0.20150804nb1:../../security/mozilla-rootcerts
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
CONFLICTS+= python-[0-9]*
python: pkgsrc changes - Fix buidling curses (consistent across platforms) - Fix finding libraries with ctypes.util.find_library - Enable spwd module on Linux - Cleanup
2018-06-17 21:21:21 +02:00
USE_LANGUAGES= c c++
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
GNU_CONFIGURE= yes
CONFIGURE_ARGS+= --enable-shared
CONFIGURE_ARGS+= --with-dbmliborder=ndbm:bdb
python: pkgsrc changes - Fix buidling curses (consistent across platforms) - Fix finding libraries with ctypes.util.find_library - Enable spwd module on Linux - Cleanup
2018-06-17 21:21:21 +02:00
CONFIGURE_ARGS+= --with-system-ffi
CONFIGURE_ARGS+= --with-threads
Add MKDIR_P to the configure env.
2013-04-17 12:00:57 +02:00
CONFIGURE_ENV+= MKDIR_P=${MKDIR:Q}
python27: updated to 2.7.16 Python 2.7.16 is a bugfix release in the Python 2.7 series.
2019-03-05 13:43:40 +01:00
CONFIGURE_ENV+= OPT=${CFLAGS:M*:Q}
Fixes missing rpath in pkg-config file. Bump PKGREVISION.
2013-11-10 13:12:32 +01:00
PKGCONFIG_OVERRIDE+= Misc/python.pc.in
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
LDFLAGS+= -L${WRKSRC}
# $RANDOM usage there is fine
CHECK_PORTABILITY_SKIP= Tools/faqwiz/move-faqwiz.sh
Fix SCO OpenServer 5.0.7/3.2 build.
2014-07-17 17:26:49 +02:00
PTHREAD_OPTS+= require
PTHREAD_AUTO_VARS= yes
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
.include "../../mk/pthread.buildlink3.mk"
.if ${PTHREAD_TYPE} == "pth"
CONFIGURE_ARGS+= --with-pth
.endif
One again, fix for Clang and interger overflow, this time is should be correct
2011-09-16 10:50:44 +02:00
.include "../../mk/compiler.mk"
# Clang needs -fwrapv
.if !empty(PKGSRC_COMPILER:Mclang)
CFLAGS+= -fwrapv
.endif
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
.include "../../mk/bsd.prefs.mk"
# fdatasync()
LIBS.SunOS+= -lrt
PY_VER_SUFFIX= 2.7
.if ${OPSYS} == "NetBSD"
# XXX work around a botched autoconf check which ignores libintl
CONFIGURE_ENV+= ac_cv_func_bind_textdomain_codeset=yes
.endif
Cygwin also require gmake to build.
2013-04-13 14:55:53 +02:00
.if ${OPSYS} == "Cygwin" || ${OPSYS} == "Darwin" || ${OPSYS} == "Interix"
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
PY_PLATNAME= ${LOWER_OPSYS}
USE_TOOLS+= gmake
.elif ${OPSYS} == "IRIX"
PY_PLATNAME= ${LOWER_OPSYS:C/\..*//}
.elif ${OPSYS} == "SunOS"
PY_PLATNAME= sunos${OS_VERSION:C/\..*//}
.elif ${OPSYS} == "HPUX"
PY_PLATNAME= hp-ux11
"sys.platform is now always 'linux2' on Linux", so revert the linux3 handling and always set PY_PLATNAME to 'linux2'.
2012-05-10 10:10:00 +02:00
.elif ${OPSYS} == "Linux"
PY_PLATNAME= linux2
Fix SCO OpenServer 5.0.7/3.2 build.
2014-07-17 17:26:49 +02:00
.elif ${OS_VARIANT} == "SCOOSR5"
PY_PLATNAME= sco_sv3
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
.else
PY_PLATNAME= ${LOWER_OPSYS}${OS_VERSION:C/\..*//}
.endif
PLIST_SUBST+= PY_PLATNAME=${PY_PLATNAME:Q}
Use LP64PLATFORMS instead of a hardcoded list. PR 51166. Fixes mips64, aargh64, and several others. XXX: make needs a better way to express this logic.
2016-05-26 06:07:32 +02:00
.if !empty(LP64PLATFORMS:@.PLAT.@${MACHINE_PLATFORM:M${.PLAT.}}@) || \
Remove references to amd64, MACHINE_ARCH x86_64 cover all variants of this architecture in pkgsrc now. Reviewed by wiz@
2015-11-08 16:08:00 +01:00
(defined(ABI) && ${ABI} == "64")
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
IS_64BIT_PLATFORM?= yes
.else
IS_64BIT_PLATFORM?= no
.endif
python: Don't install nis_failed.so if no yp headers Because python won't even try to build it. You only see nis_failed.so if there is an error building it, when it wanted to build it, and that should be fixed accordingly. In a nutshell, if the yp headers are installed, python will build the nis module, otherwise it won't. On netbsd systems at least, if you have the yp headers installed and subsequently re-install over the top with MKYP=no you get into the state where the headers are installed, but the functions are no longer in libc. This is an error with *your* system - either rebuild with MKYP=yes OR remove the yp headers from include/rpc and include/rpcsvc. Follow on fix for PR pkg/53673.
2019-04-25 17:59:54 +02:00
PLIST_VARS+= dl dll extra-so nis qt
Fix for Darwin/Xcode 10 (missing QuickTime.framework); PLIST_VARS cleanup
2018-09-28 13:01:37 +02:00
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
# the dl module isn't built for 64 bit archs
.if empty(IS_64BIT_PLATFORM:M[yY][eE][sS])
PLIST.dl= yes
.endif
# setup.py causes some modules to be built if the platform is *not* 64bit.
.if !empty(IS_64BIT_PLATFORM:M[nN][oO])
PLIST.extra-so= yes
.endif
Search the SDK path on OSX, otherwise for Xcode 5 certain modules will not be built, due to the headers not being installed in /usr/include by default.
2013-12-12 12:34:23 +01:00
# For Xcode 5 we need to search the SDK path for headers, otherwise certain
# modules will not be built.
Fix for Darwin/Xcode 10 (missing QuickTime.framework); PLIST_VARS cleanup
2018-09-28 13:01:37 +02:00
.if ${OPSYS} == "Darwin"
. if exists(${OSX_SDK_PATH}/usr/include)
CFLAGS+= -I${OSX_SDK_PATH:Q}/usr/include
. endif
. if exists(${OSX_SDK_PATH}/System/Library/Frameworks/QuickTime.framework)
PLIST.qt= yes
. endif
Search the SDK path on OSX, otherwise for Xcode 5 certain modules will not be built, due to the headers not being installed in /usr/include by default.
2013-12-12 12:34:23 +01:00
.endif
python*: rework logic used to determine if PLIST.nis is used. Match the logic used by setup.py: it looks for two headers in the default include path. This helps newer glibc linux. Omit PLIST.dll on python3* because it doesn't appear in the PLIST. Make PLIST.dll true on all non-IRIX. tested: NetBSD-current, FreeBSD 11.2, Ubuntu 18.10, CentOS 6.9, Source Mage From Dr. Thomas Orgis, myself, and with pointers to a change from leot. PR pkg/53673
2019-04-03 15:17:27 +02:00
.if ${OPSYS} != "IRIX"
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
PLIST.dll= yes
python*: rework logic used to determine if PLIST.nis is used. Match the logic used by setup.py: it looks for two headers in the default include path. This helps newer glibc linux. Omit PLIST.dll on python3* because it doesn't appear in the PLIST. Make PLIST.dll true on all non-IRIX. tested: NetBSD-current, FreeBSD 11.2, Ubuntu 18.10, CentOS 6.9, Source Mage From Dr. Thomas Orgis, myself, and with pointers to a change from leot. PR pkg/53673
2019-04-03 15:17:27 +02:00
.endif
.for incdir in ${_OPSYS_INCLUDE_DIRS}
. if (exists(${incdir}/rpc/rpc.h) || exists(${incdir}/tirpc/rpc/rpc.h))
HAVE_RPC_H= yes
. endif
. if (exists(${incdir}/rpcsvc/yp_prot.h) || exists(${incdir}/nsl/rpcsvc/yp_prot.h))
HAVE_YP_PROT_H= yes
. endif
.endfor
.if (${HAVE_RPC_H:Uno} == yes && ${HAVE_YP_PROT_H:Uno} == yes)
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
PLIST.nis= yes
.endif
# configure complains about buggy getaddrinfo()
Use OPSYSVARS.
2016-02-25 15:42:55 +01:00
CONFIGURE_ARGS.OSF1+= --disable-ipv6
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
PLIST_SUBST+= PY_VER_SUFFIX=${PY_VER_SUFFIX:Q}
TEST_TARGET= test
INSTALL_TARGET= altinstall
REPLACE_INTERPRETER+= py27
REPLACE.py27.old= .*python[^ ]*
REPLACE.py27.new= ${PREFIX}/bin/python${PY_VER_SUFFIX}
python: pkgsrc changes - Fix buidling curses (consistent across platforms) - Fix finding libraries with ctypes.util.find_library - Enable spwd module on Linux - Cleanup
2018-06-17 21:21:21 +02:00
REPLACE_FILES.py27= Lib/UserString.py
REPLACE_FILES.py27+= Lib/base64.py
REPLACE_FILES.py27+= Lib/cProfile.py
REPLACE_FILES.py27+= Lib/cgi.py
REPLACE_FILES.py27+= Lib/encodings/rot_13.py
REPLACE_FILES.py27+= Lib/idlelib/PyShell.py
REPLACE_FILES.py27+= Lib/keyword.py
REPLACE_FILES.py27+= Lib/lib2to3/pgen2/token.py
REPLACE_FILES.py27+= Lib/lib2to3/tests/data/different_encoding.py
REPLACE_FILES.py27+= Lib/lib2to3/tests/data/false_encoding.py
REPLACE_FILES.py27+= Lib/lib2to3/tests/pytree_idempotency.py
REPLACE_FILES.py27+= Lib/mimify.py
REPLACE_FILES.py27+= Lib/pdb.py
REPLACE_FILES.py27+= Lib/plat-mac/appletrunner.py
REPLACE_FILES.py27+= Lib/plat-mac/bundlebuilder.py
REPLACE_FILES.py27+= Lib/platform.py
REPLACE_FILES.py27+= Lib/profile.py
REPLACE_FILES.py27+= Lib/pydoc.py
REPLACE_FILES.py27+= Lib/quopri.py
REPLACE_FILES.py27+= Lib/smtpd.py
REPLACE_FILES.py27+= Lib/smtplib.py
REPLACE_FILES.py27+= Lib/symbol.py
REPLACE_FILES.py27+= Lib/tabnanny.py
python27: updated to 2.7.16 Python 2.7.16 is a bugfix release in the Python 2.7 series.
2019-03-05 13:43:40 +01:00
REPLACE_FILES.py27+= Lib/test/bisect_cmd.py
python: pkgsrc changes - Fix buidling curses (consistent across platforms) - Fix finding libraries with ctypes.util.find_library - Enable spwd module on Linux - Cleanup
2018-06-17 21:21:21 +02:00
REPLACE_FILES.py27+= Lib/test/curses_tests.py
REPLACE_FILES.py27+= Lib/test/re_tests.py
REPLACE_FILES.py27+= Lib/test/pystone.py
REPLACE_FILES.py27+= Lib/test/regrtest.py
REPLACE_FILES.py27+= Lib/timeit.py
REPLACE_FILES.py27+= Lib/trace.py
REPLACE_FILES.py27+= Lib/uu.py
REPLACE_FILES.py27+= Lib/webbrowser.py
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
Fix for libffi include path on Darwin.
2015-11-25 15:01:34 +01:00
SUBST_CLASSES+= libffi
SUBST_MESSAGE.libffi= Fixing libffi include path on Darwin.
SUBST_STAGE.libffi= pre-configure
SUBST_FILES.libffi= setup.py
SUBST_SED.libffi= -e 's,/usr/include/ffi,${BUILDLINK_PREFIX.libffi}/include,'
python27: clean-up SUBST to match other Python versions
2019-03-03 11:44:41 +01:00
# XXX: It might be needed to add manually more paths like ${PREFIX}/qt5/lib
# Test: python -c 'from ctypes.util import find_library; print(find_library("ffi"));'
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
SUBST_CLASSES+= findlib
python27: clean-up SUBST to match other Python versions
2019-03-03 11:44:41 +01:00
SUBST_MESSAGE.findlib= Fixing find_library().
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
SUBST_STAGE.findlib= pre-configure
python27: clean-up SUBST to match other Python versions
2019-03-03 11:44:41 +01:00
SUBST_FILES.findlib= Lib/ctypes/macholib/dyld.py
SUBST_FILES.findlib+= Lib/ctypes/util.py
SUBST_FILES.findlib+= Lib/distutils/unixccompiler.py
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
SUBST_SED.findlib= -e 's,/usr/local,${PREFIX},'
python27: clean-up SUBST to match other Python versions
2019-03-03 11:44:41 +01:00
SUBST_SED.findlib+= -e 's!\(-Wl,-t -o\)!${COMPILER_RPATH_FLAG}${PREFIX}/lib -L${PREFIX}/lib \1!'
python*: findlib subst class can be a noop It is licit to be a noop for findlib subst class when PREFIX is `/usr/local'. Thanks to <jklos>! (via PR pkg/54758)
2020-05-21 19:25:13 +02:00
SUBST_NOOP_OK.findlib= yes
Fixing find_library() on POSIX-like (excluding Darwin) systems. This isn't addressing Python's wrapper for dlopen(3). This possibily addresses mostly NetBSD as other popular OSes have ldconfig. Testing commands: - before applying the patch >>> from ctypes.util import find_library >>> find_library("m") 'libm.so.0' >>> find_library("crypto") 'libcrypto.so.11' >>> find_library("GL") >>> find_library("curl") - after applying the patch >>> from ctypes.util import find_library >>> find_library("m") 'libm.so.0' >>> find_library("crypto") 'libcrypto.so.11' >>> find_library("GL") 'libGL.so.2' >>> find_library("curl") 'libcurl.so.4' This patch doesn't solve the case of custom dirs like $PREFIX/qt5/lib. However it's solving most common cases of using this call. A possible solution is to parse the output "pkg_info -La"... however it's very slow. In other words a cache with libraries might be needed to handle it efficiently. Bump PKGREVISION.
2016-07-23 15:09:15 +02:00
On systems where both of the conditions 1. LD_LIBRARY_PATH does _not_ take precedence over DT_RPATH (e.g. Linux) 2. A previous libpython with the same major.minor is already installed (e.g. a previous version of this package) hold, the built python will be linked with the installed libpython, causing it to report an old teeny version in sys.version_info while staging the install. Then "make package" fails with PLIST mismatches for {,Pattern}Grammar.*.pickle. pkgsrc knows which version we're building. Pass that down instead. For platforms that weren't having this problem, no functional change intended. For platforms that were, this simply restores "make package", so no PKGREVISION bump.
2020-08-14 21:28:43 +02:00
SUBST_CLASSES+= pkgversion
SUBST_STAGE.pkgversion= pre-configure
SUBST_FILES.pkgversion= Lib/lib2to3/pgen2/driver.py
Pass down PKGVERSION_NOREV in another spot to avoid another PLIST mismatch (for Python-2.7.XX-py2.7.egg-info) on Linux systems with a previous version of this package installed.
2020-08-21 21:39:28 +02:00
SUBST_FILES.pkgversion+=Lib/distutils/command/install_egg_info.py
On systems where both of the conditions 1. LD_LIBRARY_PATH does _not_ take precedence over DT_RPATH (e.g. Linux) 2. A previous libpython with the same major.minor is already installed (e.g. a previous version of this package) hold, the built python will be linked with the installed libpython, causing it to report an old teeny version in sys.version_info while staging the install. Then "make package" fails with PLIST mismatches for {,Pattern}Grammar.*.pickle. pkgsrc knows which version we're building. Pass that down instead. For platforms that weren't having this problem, no functional change intended. For platforms that were, this simply restores "make package", so no PKGREVISION bump.
2020-08-14 21:28:43 +02:00
SUBST_VARS.pkgversion= PKGVERSION_NOREV
Add an option for Python: x11 Fix build on systems with disabled X11 Reported by <schmonz>, Andreas Kusalananda Kahari Tested by Andreas Kusalananda Kahari Possible direction is to make this switch by default disabled on Darwin.
2016-07-26 18:44:28 +02:00
.include "options.mk"
Fix build for X11_TYPE != "native" Noted by <wiz> Solution suggested by <leot>
2016-07-23 23:12:48 +02:00
Reapply reverted commit from obache@. Original description: Prevent to detect unwanted builtin openssl. After bump of BUILDLINK_API_DEPENDS.openssl to 1.0.1c, buitin openssl is not acceptable for various platforms.
2014-04-13 17:06:20 +02:00
SUBST_CLASSES+= sslbase
SUBST_MESSAGE.sslbase= Fixing find-file for openssl with SSLBASE.
SUBST_STAGE.sslbase= pre-configure
SUBST_FILES.sslbase= setup.py
SUBST_VARS.sslbase= SSLBASE
Use the "cacert.pem" file from the "mozilla-rootcerts" package as an *extra* location to load CA certificates from in the "ssl" module. HTTPS requests to a site with a valid certificate now work out of the box (even without the "mozilla-rootcerts-openssl").
2016-02-06 12:25:09 +01:00
SUBST_CLASSES+= cacert
SUBST_MESSAGE.cacert= Configuring location of default CA certificate file.
SUBST_STAGE.cacert= pre-configure
SUBST_FILES.cacert= Modules/_ssl.c
python27: updated to 2.7.16 Python 2.7.16 is a bugfix release in the Python 2.7 series.
2019-03-05 13:43:40 +01:00
SUBST_VARS.cacert= PREFIX
Use the "cacert.pem" file from the "mozilla-rootcerts" package as an *extra* location to load CA certificates from in the "ssl" module. HTTPS requests to a site with a valid certificate now work out of the box (even without the "mozilla-rootcerts-openssl").
2016-02-06 12:25:09 +01:00
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
post-extract:
For smtpd.py, only rename with ${PYVERSUFFIX} to be installed as a tool, or rename of module name affect to other parts using this module. Noticed by Benjamin Lorenz in tech-pkg@. Additionally, set ALTERNATIVE for bin/smtpd.py.
2014-03-12 13:40:57 +01:00
${LN} -s ${WRKSRC}/Lib/smtpd.py ${WRKSRC}/Tools/scripts/smtpd${PY_VER_SUFFIX}.py
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
${MV} ${WRKSRC}/Tools/scripts/pydoc ${WRKSRC}/Tools/scripts/pydoc${PY_VER_SUFFIX}
${MV} ${WRKSRC}/Tools/scripts/2to3 ${WRKSRC}/Tools/scripts/2to3-${PY_VER_SUFFIX}
.if ${OPSYS} == "HPUX"
post-install:
${LN} -fs ${DESTDIR}${PREFIX}/lib/libpython2.7.sl \
${DESTDIR}${PREFIX}/lib/libpython2.7.sl.1.0
.endif
Fix SCO OpenServer 5.0.7/3.2 build.
2014-07-17 17:26:49 +02:00
.if ${OS_VARIANT} == "SCOOSR5"
# SCO OpenServer 5.0.7/3.2 has no socklen_t in system headers, but has in
# GNU pth's header. It should be used in this case.
CONFIGURE_ENV+= ac_cv_type_socklen_t=yes
.endif
document non-obvious readline build dependency
2020-05-14 23:43:11 +02:00
# needed to make devel/py-readline pick up the correct readline implementation
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
BUILDLINK_DEPMETHOD.readline= build
.include "../../archivers/bzip2/buildlink3.mk"
.include "../../devel/gettext-lib/buildlink3.mk"
.include "../../devel/libffi/buildlink3.mk"
.include "../../devel/readline/buildlink3.mk"
.include "../../devel/zlib/buildlink3.mk"
.include "../../security/openssl/buildlink3.mk"
Put back bdb bl3, required for the dbm module.
2017-02-01 12:31:50 +01:00
.include "../../mk/bdb.buildlink3.mk"
Import python27-2.7.1 as lang/python27. Python 2.7 is intended to be the last major release in the 2.x series. The Python maintainers are planning to focus their future efforts on the Python 3.x series. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x continues, and the developers are planning to support Python 2.7 with bug-fix releases beyond the typical two years. * A policy decision was made to silence warnings only of interest to developers. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. This change was also made in the branch that will become Python 3.2. (Discussed on stdlib-sig and carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening application developers with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault <-W>` (short form: :option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS` environment variable to ``"default"`` (or ``"d"``) before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``.
2011-02-22 09:51:58 +01:00
.include "../../mk/dlopen.buildlink3.mk"
.include "../../mk/bsd.pkg.mk"
Reference in a new issue Copy permalink