mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-11-27 07:21:09 +08:00
Code Issues Packages Projects Releases Wiki Activity
8f3be9661f
postgresql/config/python.m4

99 lines
3.7 KiB
Plaintext
Raw Normal View History

Moved the intricacies of the perl interface build into its own makefile that now functions as a wrapper around the MakeMaker stuff. It might even behave sensically when we have separate build dirs. Same for plperl, which of course still doesn't work very well. Made sure that plperl respects the choice of --libdir. Added --with-python to automatically build and install the Python interface. Works similarly to the Perl5 stuff. Moved the burden of the distclean targets lower down into the source tree. Eventually, each make file should have its own. Added automatic remaking of makefiles and configure. Currently only for the top-level because of a bug(?) in Autoconf. Use GNU `missing' to work around missing autoconf and aclocal. Start factoring out macros into their own config/*.m4 files to increase readability and organization.
2000-06-11 02:02:12 +08:00
#
# Autoconf macros for configuring the build of Python extension modules
#
Remove cvs keywords from all files.
2010-09-21 04:08:53 +08:00
# config/python.m4
Moved the intricacies of the perl interface build into its own makefile that now functions as a wrapper around the MakeMaker stuff. It might even behave sensically when we have separate build dirs. Same for plperl, which of course still doesn't work very well. Made sure that plperl respects the choice of --libdir. Added --with-python to automatically build and install the Python interface. Works similarly to the Perl5 stuff. Moved the burden of the distclean targets lower down into the source tree. Eventually, each make file should have its own. Added automatic remaking of makefiles and configure. Currently only for the top-level because of a bug(?) in Autoconf. Use GNU `missing' to work around missing autoconf and aclocal. Start factoring out macros into their own config/*.m4 files to increase readability and organization.
2000-06-11 02:02:12 +08:00
#
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
# PGAC_PATH_PYTHON
Moved the intricacies of the perl interface build into its own makefile that now functions as a wrapper around the MakeMaker stuff. It might even behave sensically when we have separate build dirs. Same for plperl, which of course still doesn't work very well. Made sure that plperl respects the choice of --libdir. Added --with-python to automatically build and install the Python interface. Works similarly to the Perl5 stuff. Moved the burden of the distclean targets lower down into the source tree. Eventually, each make file should have its own. Added automatic remaking of makefiles and configure. Currently only for the top-level because of a bug(?) in Autoconf. Use GNU `missing' to work around missing autoconf and aclocal. Start factoring out macros into their own config/*.m4 files to increase readability and organization.
2000-06-11 02:02:12 +08:00
# ----------------
Upgrade to Autoconf version 2.53. Replaced many custom macro calls with new or now-built-in versions. Make sure that all calls to AC_DEFINE have a third argument, for possible use of autoheader in the future.
2002-03-30 01:32:55 +08:00
# Look for Python and set the output variable 'PYTHON'
# to 'python' if found, empty otherwise.
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
AC_DEFUN([PGAC_PATH_PYTHON],
[AC_PATH_PROG(PYTHON, python)
if test x"$PYTHON" = x""; then
AC_MSG_ERROR([Python not found])
fi
])
# _PGAC_CHECK_PYTHON_DIRS
# -----------------------
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
# Determine the name of various directories of a given Python installation.
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
AC_DEFUN([_PGAC_CHECK_PYTHON_DIRS],
[AC_REQUIRE([PGAC_PATH_PYTHON])
Make discovery of python_configdir architecture independent. Solution from James William Pye.
2004-09-17 07:30:30 +08:00
AC_MSG_CHECKING([for Python distutils module])
In the configure check for the Python distutils module, use a less obscure shell construct to hide away the stderr output. Python 3.1 actually core dumps on the current invocation (http://bugs.python.org/issue7111), but the new version also has the more general advantage of saving the error message in config.log for analysis.
2009-10-15 05:59:15 +08:00
if "${PYTHON}" -c 'import distutils' 2>&AS_MESSAGE_LOG_FD
Make discovery of python_configdir architecture independent. Solution from James William Pye.
2004-09-17 07:30:30 +08:00
then
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT(no)
AC_MSG_ERROR([distutils module not found])
fi
Un-break plpython build for non-Windows platforms.
2004-10-11 03:07:55 +08:00
AC_MSG_CHECKING([Python configuration directory])
Python 3 support in PL/Python Behaves more or less unchanged compared to Python 2, but the new language variant is called plpython3u. Documentation describing the naming scheme is included.
2009-12-16 06:59:55 +08:00
python_majorversion=`${PYTHON} -c "import sys; print(sys.version[[0]])"`
Allow configure to deal with Python 3.0. Changes were: print foo --> print(foo) string.join(...) --> ' '.join(...) These changes are backward compatible. The actual plpython module appears to need significant updates to support Python 3.0, though. This change just relieves interested developers from having to deal with Autoconf.
2009-01-04 08:54:15 +08:00
python_version=`${PYTHON} -c "import sys; print(sys.version[[:3]])"`
python.m4: Remove useless "import string" calls They have been unneeded since the use of the string module has been removed in a65ed83f8a6fbf35c1e563533ab8293a788b1fce.
2011-11-29 12:50:11 +08:00
python_configdir=`${PYTHON} -c "import distutils.sysconfig; print(' '.join(filter(None,distutils.sysconfig.get_config_vars('LIBPL'))))"`
Also check for Python platform-specific include directory Python can be built to have two separate include directories: one for platform-independent files and one for platform-specific files. So far, this has apparently never mattered for a PL/Python build. But with the new multi-arch Python packages in Debian and Ubuntu, this is becoming the standard configuration on these platforms, so we must check these directories separately to be able to build there. Also add a bit of reporting in configure to be able to see better what is going on with this.
2012-08-30 10:44:59 +08:00
AC_MSG_RESULT([$python_configdir])
AC_MSG_CHECKING([Python include directories])
python_includespec=`${PYTHON} -c "
import distutils.sysconfig
a = '-I' + distutils.sysconfig.get_python_inc(False)
b = '-I' + distutils.sysconfig.get_python_inc(True)
if a == b:
print(a)
else:
print(a + ' ' + b)"`
AC_MSG_RESULT([$python_includespec])
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
Python 3 support in PL/Python Behaves more or less unchanged compared to Python 2, but the new language variant is called plpython3u. Documentation describing the naming scheme is included.
2009-12-16 06:59:55 +08:00
AC_SUBST(python_majorversion)[]dnl
Un-break plpython build for non-Windows platforms.
2004-10-11 03:07:55 +08:00
AC_SUBST(python_version)[]dnl
Support fake root install, separate build dir, dependency tracking, our choice of compiler and flags, uninstall, and peculiar Python installation layouts for PyGreSql. Also install into site-packages now, as officially recommended. And pgdb.py is also installed now, used to be forgotten.
2001-07-11 00:33:02 +08:00
AC_SUBST(python_includespec)[]dnl
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
])# _PGAC_CHECK_PYTHON_DIRS
Moved the intricacies of the perl interface build into its own makefile that now functions as a wrapper around the MakeMaker stuff. It might even behave sensically when we have separate build dirs. Same for plperl, which of course still doesn't work very well. Made sure that plperl respects the choice of --libdir. Added --with-python to automatically build and install the Python interface. Works similarly to the Perl5 stuff. Moved the burden of the distclean targets lower down into the source tree. Eventually, each make file should have its own. Added automatic remaking of makefiles and configure. Currently only for the top-level because of a bug(?) in Autoconf. Use GNU `missing' to work around missing autoconf and aclocal. Start factoring out macros into their own config/*.m4 files to increase readability and organization.
2000-06-11 02:02:12 +08:00
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
# PGAC_CHECK_PYTHON_EMBED_SETUP
# -----------------------------
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
#
# Note: selecting libpython from python_configdir works in all Python
# releases, but it generally finds a non-shared library, which means
# that we are binding the python interpreter right into libplpython.so.
# In Python 2.3 and up there should be a shared library available in
# the main library location.
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
AC_DEFUN([PGAC_CHECK_PYTHON_EMBED_SETUP],
[AC_REQUIRE([_PGAC_CHECK_PYTHON_DIRS])
AC_MSG_CHECKING([how to link an embedded Python application])
python.m4: Remove useless "import string" calls They have been unneeded since the use of the string module has been removed in a65ed83f8a6fbf35c1e563533ab8293a788b1fce.
2011-11-29 12:50:11 +08:00
python_libdir=`${PYTHON} -c "import distutils.sysconfig; print(' '.join(filter(None,distutils.sysconfig.get_config_vars('LIBDIR'))))"`
python_ldlibrary=`${PYTHON} -c "import distutils.sysconfig; print(' '.join(filter(None,distutils.sysconfig.get_config_vars('LDLIBRARY'))))"`
python_so=`${PYTHON} -c "import distutils.sysconfig; print(' '.join(filter(None,distutils.sysconfig.get_config_vars('SO'))))"`
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
ldlibrary=`echo "${python_ldlibrary}" | sed "s/${python_so}$//"`
PL/Python: Make build on OS X more flexible The PL/Python build on OS X was previously hardcoded to use the system installation of Python, ignoring whatever was specified to configure. Except that it would use the header files from configure, which could lead to mismatches. It was not possible to build against a custom Python installation. Now, we check in configure how the specified Python installation was built and use that, supporting framework and non-framework builds.
2013-01-05 21:56:14 +08:00
python_enable_shared=`${PYTHON} -c "import distutils.sysconfig; print(distutils.sysconfig.get_config_vars().get('Py_ENABLE_SHARED',0))"`
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
On OS X, link libpython normally, ignoring the "framework" framework. As of Xcode 5.0, Apple isn't including the Python framework as part of the SDK-level files, which means that linking to it might fail depending on whether Xcode thinks you've selected a specific SDK version. According to their Tech Note 2328, they've basically deprecated the framework method of linking to libpython and are telling people to link to the shared library normally. (I'm pretty sure this is in direct contradiction to the advice they were giving a few years ago, but whatever.) Testing says that this approach works fine at least as far back as OS X 10.4.11, so let's just rip out the framework special case entirely. We do still need a special case to decide that OS X provides a shared library at all, unfortunately (I wonder why the distutils check doesn't work ...). But this is still less of a special case than before, so it's fine. Back-patch to all supported branches, since we'll doubtless be hearing about this more as more people update to recent Xcode.
2014-05-31 06:18:14 +08:00
if test x"${python_libdir}" != x"" -a x"${python_ldlibrary}" != x"" -a x"${python_ldlibrary}" != x"${ldlibrary}"
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
then
# New way: use the official shared library
ldlibrary=`echo "${ldlibrary}" | sed "s/^lib//"`
python_libspec="-L${python_libdir} -l${ldlibrary}"
else
# Old way: use libpython from python_configdir
python_libdir="${python_configdir}"
Improve detection of Python 3.2 installations Because of ABI tagging, the library version number might no longer be exactly the Python version number, so do extra lookups. This affects installations without a shared library, such as ActiveState's installer. Also update the way to detect the location of the 'config' directory, which can also be versioned. Ashesh Vashi
2011-08-18 19:43:16 +08:00
# LDVERSION was introduced in Python 3.2.
python.m4: Remove useless "import string" calls They have been unneeded since the use of the string module has been removed in a65ed83f8a6fbf35c1e563533ab8293a788b1fce.
2011-11-29 12:50:11 +08:00
python_ldversion=`${PYTHON} -c "import distutils.sysconfig; print(' '.join(filter(None,distutils.sysconfig.get_config_vars('LDVERSION'))))"`
Improve detection of Python 3.2 installations Because of ABI tagging, the library version number might no longer be exactly the Python version number, so do extra lookups. This affects installations without a shared library, such as ActiveState's installer. Also update the way to detect the location of the 'config' directory, which can also be versioned. Ashesh Vashi
2011-08-18 19:43:16 +08:00
if test x"${python_ldversion}" = x""; then
python_ldversion=$python_version
fi
python_libspec="-L${python_libdir} -lpython${python_ldversion}"
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
fi
On OS X, link libpython normally, ignoring the "framework" framework. As of Xcode 5.0, Apple isn't including the Python framework as part of the SDK-level files, which means that linking to it might fail depending on whether Xcode thinks you've selected a specific SDK version. According to their Tech Note 2328, they've basically deprecated the framework method of linking to libpython and are telling people to link to the shared library normally. (I'm pretty sure this is in direct contradiction to the advice they were giving a few years ago, but whatever.) Testing says that this approach works fine at least as far back as OS X 10.4.11, so let's just rip out the framework special case entirely. We do still need a special case to decide that OS X provides a shared library at all, unfortunately (I wonder why the distutils check doesn't work ...). But this is still less of a special case than before, so it's fine. Back-patch to all supported branches, since we'll doubtless be hearing about this more as more people update to recent Xcode.
2014-05-31 06:18:14 +08:00
python_additional_libs=`${PYTHON} -c "import distutils.sysconfig; print(' '.join(filter(None,distutils.sysconfig.get_config_vars('LIBS','LIBC','LIBM','BASEMODLIBS'))))"`
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
AC_MSG_RESULT([${python_libspec} ${python_additional_libs}])
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
AC_SUBST(python_libdir)[]dnl
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
AC_SUBST(python_libspec)[]dnl
Another try at making plpython autoconfiguration work correctly. Use a -L spec rather than assuming libpython is in the standard search path (this returns to the way 7.4 did it). But check the distutils output to see if it looks like Python has built a shared library, and if so link with that instead of the probably-not-shared library found in configdir.
2004-10-12 03:32:19 +08:00
AC_SUBST(python_additional_libs)[]dnl
PL/Python: Make build on OS X more flexible The PL/Python build on OS X was previously hardcoded to use the system installation of Python, ignoring whatever was specified to configure. Except that it would use the header files from configure, which could lead to mismatches. It was not possible to build against a custom Python installation. Now, we check in configure how the specified Python installation was built and use that, supporting framework and non-framework builds.
2013-01-05 21:56:14 +08:00
AC_SUBST(python_enable_shared)[]dnl
Prevent threaded python build on BSD's, where it fails. Marko Kreen
2005-09-27 00:48:28 +08:00
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-13 01:49:32 +08:00
])# PGAC_CHECK_PYTHON_EMBED_SETUP
Reference in New Issue Copy Permalink