public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* Allow building GDB with Python support on Windows/MinGW
@ 2011-01-22 23:45 Joel Brobecker
  2011-01-22 23:45 ` [RFA 2/2] allow building GDB with Python support on MinGW Joel Brobecker
  2011-01-23  0:14 ` [RFA 1/2] do not use python<version> subdir when including Python .h file Joel Brobecker
  0 siblings, 2 replies; 9+ messages in thread
From: Joel Brobecker @ 2011-01-22 23:45 UTC (permalink / raw)
  To: gdb-patches

This set of patches makes the necessary changes to able to build
GDB with Python support on Windows/MinGW.  The patches are a little
different from the first one I posted a few days ago
(http://www.sourceware.org/ml/gdb-patches/2011-01/msg00431.html),
as I went back and forth between several options.  But I think
that the current set ended up being the cleanest of al.

This work certained made me raise the question of whether we really
want to support so many ways of building GDB with Python.  But that's
for another discussion...

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [RFA 2/2] allow building GDB with Python support on MinGW
  2011-01-22 23:45 Allow building GDB with Python support on Windows/MinGW Joel Brobecker
@ 2011-01-22 23:45 ` Joel Brobecker
  2011-01-28 11:32   ` Tom Tromey
  2011-01-23  0:14 ` [RFA 1/2] do not use python<version> subdir when including Python .h file Joel Brobecker
  1 sibling, 1 reply; 9+ messages in thread
From: Joel Brobecker @ 2011-01-22 23:45 UTC (permalink / raw)
  To: gdb-patches; +Cc: Joel Brobecker

This makes several adjustements to the configure python-config.py
scripts to deal with the differences between a Unix install of Python
and a Windows install of Python (as downloaded from the Python website).

Differences:

  - The Python executable is directly in the python prefix directory
    as opposed to inside the bin/ subdirectory.

  - The name of the python library is does not have a dot in the version
    number: On Unix, we have libpython2.7, while on Windows, it's
    libpython27.  So the regexp extracting the python version from
    the Python lib filename had to be adjusted slightly.

    Also, the tests checking the name of the libpython had to be
    adjusted to allow for that.

  - There are no link options following the -lpython<version> switch
    on Windows, but the regexp extracting the python version was
    using it as a delimiter.  It had to be removed.

  - python-config.py does not work on Windows, mostly because
    some sysconfig variables are missing.  They are not necessary
    so the script was adapted to skip them if not defined.

  - The paths returned by python-config.py follow the Windows filename
    convention in terms of the directory separator, and this is causing
    trouble when the build environment is cygwin (while the compiler
    and Python are MinGW).  We could have fixed that in the configure
    script, but it felt simpler to do so in python-config.py

gdb/ChangeLog:

        * configure.ac: Add handling of Python distribution on Windows.
        * python-config.py: If the LIBS, SYSLIBS, LIBPL and/or LINKFORSHARED
        sysconfig variables are not defined, then do not use them.
        On Windows, if LIBPL is not defined, then use prefix + '/libs'
        instead.  On Windows, return all paths using forward-slashes
        rather than backslashes.

Tested on x86_64-linux.  Python gets sucessfully built in MinGW/GDB,
and simple Python commands seem to work.

---
 gdb/configure               |   17 ++++++++++++-----
 gdb/configure.ac            |   17 ++++++++++++-----
 gdb/python/python-config.py |   34 +++++++++++++++++++++++++++-------
 3 files changed, 51 insertions(+), 17 deletions(-)

diff --git a/gdb/configure b/gdb/configure
index 2540f8b..5a6d0be 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -10478,6 +10478,13 @@ else
       # Assume the python binary is ${with_python}/bin/python.
       python_prog="${with_python}/bin/python"
       python_prefix=
+      # If python does not exit ${with_python}/bin, then try in
+      # ${with_python}.  On Windows/MinGW, this is where the Python
+      # executable is.
+      if test ! -x "${python_prog}"; then
+        python_prog="${with_python}/python"
+        python_prefix=
+      fi
       if test ! -x "${python_prog}"; then
         # Fall back to gdb 7.0/7.1 behaviour.
         python_prog=missing
@@ -10652,7 +10659,7 @@ fi
   have_libpython=no
   if test "${have_python_config}" = yes; then
     python_version=`echo " ${python_libs} " \
-                         | sed -e 's,^.* -l\(python[0-9]*[.][0-9]*\) .*$,\1,'`
+                         | sed -e 's,^.* -l\(python[0-9]*[.]\?[0-9]*\).*$,\1,'`
     case "${python_version}" in
     python*)
 
@@ -10850,19 +10857,19 @@ $as_echo "${found_usable_python}" >&6; }
 
     fi
   fi
-  if test "${have_libpython}" = python2.7; then
+  if test "${have_libpython}" = python2.7 -o "${have_libpython}" = python27; then
 
 $as_echo "#define HAVE_LIBPYTHON2_7 1" >>confdefs.h
 
-  elif test "${have_libpython}" = python2.6; then
+  elif test "${have_libpython}" = python2.6 -o "${have_libpython}" = python26; then
 
 $as_echo "#define HAVE_LIBPYTHON2_6 1" >>confdefs.h
 
-  elif test "${have_libpython}" = python2.5; then
+  elif test "${have_libpython}" = python2.5 -o "${have_libpython}" = python25; then
 
 $as_echo "#define HAVE_LIBPYTHON2_5 1" >>confdefs.h
 
-  elif test "${have_libpython}" = python2.4; then
+  elif test "${have_libpython}" = python2.4 -o "${have_libpython}" = python24; then
 
 $as_echo "#define HAVE_LIBPYTHON2_4 1" >>confdefs.h
 
diff --git a/gdb/configure.ac b/gdb/configure.ac
index afb7314..68b0838 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -669,6 +669,13 @@ else
       # Assume the python binary is ${with_python}/bin/python.
       python_prog="${with_python}/bin/python"
       python_prefix=
+      # If python does not exit ${with_python}/bin, then try in
+      # ${with_python}.  On Windows/MinGW, this is where the Python
+      # executable is.
+      if test ! -x "${python_prog}"; then
+        python_prog="${with_python}/python"
+        python_prefix=
+      fi
       if test ! -x "${python_prog}"; then
         # Fall back to gdb 7.0/7.1 behaviour.
         python_prog=missing
@@ -763,7 +770,7 @@ else
   have_libpython=no
   if test "${have_python_config}" = yes; then
     python_version=`echo " ${python_libs} " \
-                         | sed -e 's,^.* -l\(python[[0-9]]*[[.]][[0-9]]*\) .*$,\1,'`
+                         | sed -e 's,^.* -l\(python[[0-9]]*[[.]]\?[[0-9]]*\).*$,\1,'`
     case "${python_version}" in
     python*)
       AC_TRY_LIBPYTHON(${python_version}, have_libpython,
@@ -791,13 +798,13 @@ else
                        ${python_includes}, "${python_libs} -lpython2.4")
     fi
   fi
-  if test "${have_libpython}" = python2.7; then
+  if test "${have_libpython}" = python2.7 -o "${have_libpython}" = python27; then
     AC_DEFINE(HAVE_LIBPYTHON2_7, 1, [Define if Python 2.7 is being used.])
-  elif test "${have_libpython}" = python2.6; then
+  elif test "${have_libpython}" = python2.6 -o "${have_libpython}" = python26; then
     AC_DEFINE(HAVE_LIBPYTHON2_6, 1, [Define if Python 2.6 is being used.])
-  elif test "${have_libpython}" = python2.5; then
+  elif test "${have_libpython}" = python2.5 -o "${have_libpython}" = python25; then
     AC_DEFINE(HAVE_LIBPYTHON2_5, 1, [Define if Python 2.5 is being used.])
-  elif test "${have_libpython}" = python2.4; then
+  elif test "${have_libpython}" = python2.4 -o "${have_libpython}" = python24; then
     AC_DEFINE(HAVE_LIBPYTHON2_4, 1, [Define if Python 2.4 is being used.])
   fi
 
diff --git a/gdb/python/python-config.py b/gdb/python/python-config.py
index 0230eb4..75ed2d2 100644
--- a/gdb/python/python-config.py
+++ b/gdb/python/python-config.py
@@ -30,28 +30,48 @@ opt_flags = [flag for (flag, val) in opts]
 if '--help' in opt_flags:
     exit_with_usage(code=0)
 
+def to_unix_path(path):
+    """On Windows, returns the given path with all backslashes
+    converted into forward slashes.  This is to help prevent problems
+    when using the paths returned by this script with cygwin tools.
+    In particular, cygwin bash treats backslashes as a special character.
+
+    On Unix systems, returns the path unchanged.
+    """
+    if os.name == 'nt':
+        path = path.replace('\\', '/')
+    return path
+
 for opt in opt_flags:
     if opt == '--prefix':
-        print sysconfig.PREFIX
+        print to_unix_path(sysconfig.PREFIX)
 
     elif opt == '--exec-prefix':
-        print sysconfig.EXEC_PREFIX
+        print to_unix_path(sysconfig.EXEC_PREFIX)
 
     elif opt in ('--includes', '--cflags'):
         flags = ['-I' + sysconfig.get_python_inc(),
                  '-I' + sysconfig.get_python_inc(plat_specific=True)]
         if opt == '--cflags':
             flags.extend(getvar('CFLAGS').split())
-        print ' '.join(flags)
+        print to_unix_path(' '.join(flags))
 
     elif opt in ('--libs', '--ldflags'):
-        libs = getvar('LIBS').split() + getvar('SYSLIBS').split()
+        libs = []
+        if getvar('LIBS') is not None:
+            libs.extend(getvar('LIBS').split())
+        if getvar('SYSLIBS') is not None:
+            libs.extend(getvar('SYSLIBS').split())
         libs.append('-lpython'+pyver)
         # add the prefix/lib/pythonX.Y/config dir, but only if there is no
         # shared library in prefix/lib/.
         if opt == '--ldflags':
             if not getvar('Py_ENABLE_SHARED'):
-                libs.insert(0, '-L' + getvar('LIBPL'))
-            libs.extend(getvar('LINKFORSHARED').split())
-        print ' '.join(libs)
+                if getvar('LIBPL') is not None:
+                    libs.insert(0, '-L' + getvar('LIBPL'))
+                elif os.name == 'nt':
+                    libs.insert(0, '-L' + sysconfig.PREFIX + '/libs')
+            if getvar('LINKFORSHARED') is not None:
+                libs.extend(getvar('LINKFORSHARED').split())
+        print to_unix_path(' '.join(libs))
 
-- 
1.7.1

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [RFA 1/2] do not use python<version> subdir when including Python .h file
  2011-01-22 23:45 Allow building GDB with Python support on Windows/MinGW Joel Brobecker
  2011-01-22 23:45 ` [RFA 2/2] allow building GDB with Python support on MinGW Joel Brobecker
@ 2011-01-23  0:14 ` Joel Brobecker
  2011-01-28 11:24   ` Tom Tromey
  2011-01-31  4:44   ` Joel Brobecker
  1 sibling, 2 replies; 9+ messages in thread
From: Joel Brobecker @ 2011-01-23  0:14 UTC (permalink / raw)
  To: gdb-patches; +Cc: Joel Brobecker

This is preparation work for being able to build GDB with Python
support on MinGW.

So far, the "python<version>" subdirectory needs to be specified
when including a Python header file.  In order to do that, we have
some special configury that tweaks the include path returned by
python-config.py such that the use of the subdirectory in the include
is necessary.  This was done in order to protect ourselves from
possible filename conflicts, since some of the filenames chosen by
Python were a little generic.

The problem is that this cannot work with a standard Python install
on MinGW systems.  On such systems, the .h files are located in
<python_prefix>/include.  So, in preparation for allowing us to build
GDB on MinGW with Python support enabled, this patch changes the
requirement to provide the "python<version>" subdirectory in the
include directive.

The positive consequence is that we no longer need to have a set
of #include directives for each version of Python, since the include
directive is now the same for all versions of Python.  However, the
downside is that we are losing the level of protection we were trying
to achieve by forcing the subdirectory in the include directive.
In order to reduce a bit the consequences of a possible conflict,
this patch also changes the location where the -I/path/to/python
switch goes, to be last in the list (suggested by Doug Evans).

One last change is the fact that we are now including Python.h
and all other Python include headers using angle brackets rather
than double-quotes.  This fixes a problem on case-insensitive
systems where #include "Python.h" causes our gdb/python/python.h
header to be included instead of Python's <Python.h> header.

gdb/ChangeLog:

	* configure.ac: Remove fallback behavior for building
	against Python.  Remove tweaking of Python include path.
	Add PYTHON_CPPFLAGS and PYTHON_LIBS substitution.
	(AC_TRY_LIBPYTHON):  Adjust program used in linking test.
	If link is successful, set PYTHON_CPPFLAGS and PYTHON_LIBS.
	Always restore CPPFLAGS and LIBS after linking test.
	* configure: Regenerated.
	* Makefile.in (INTERNAL_CPPFLAGS): Add @PYTHON_CPPFLAGS@.
	(INSTALLED_LIBS, CLIBS): Add @PYTHON_LIBS@.
	* python/python-internal.h: Adjust includes of Python .h files.

Tested on x86_64-linux.

---
 gdb/Makefile.in              |   13 +++++--
 gdb/configure                |   73 ++++++++++++++++++++---------------------
 gdb/configure.ac             |   36 ++++++++------------
 gdb/python/python-internal.h |   18 +++-------
 4 files changed, 65 insertions(+), 75 deletions(-)

diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 226faf6..d8efc84 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -408,8 +408,13 @@ PROFILE_CFLAGS = @PROFILE_CFLAGS@
 # when running make.  I.E.  "make CFLAGS=-Wmissing-prototypes".
 CFLAGS = @CFLAGS@
 
-# Set by configure, for e.g. expat.
-INTERNAL_CPPFLAGS = @CPPFLAGS@
+# Set by configure, for e.g. expat.  Python installations are such that
+# C headers are included using their basename (for example, we #include
+# <Python.h> rather than, say, <python/Python.h>).  Since the file names
+# are sometimes a little generic, we think that the risk of collision
+# with other header files is high.  If that happens, we try to mitigate
+# a bit the consequences by putting the Python includes last in the list.
+INTERNAL_CPPFLAGS = @CPPFLAGS@ @PYTHON_CPPFLAGS@
 
 # Need to pass this to testsuite for "make check".  Probably should be
 # consistent with top-level Makefile.in and gdb/testsuite/Makefile.in
@@ -444,10 +449,10 @@ INTERNAL_LDFLAGS = $(CFLAGS) $(GLOBAL_CFLAGS) $(MH_LDFLAGS) $(LDFLAGS) $(CONFIG_
 # If you have the Cygnus libraries installed,
 # you can use 'CLIBS=$(INSTALLED_LIBS)' 'CDEPS='
 INSTALLED_LIBS=-lbfd -lreadline -lopcodes -liberty -ldecnumber \
-	$(XM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) @LIBS@ \
+	$(XM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) @LIBS@ @PYTHON_LIBS@ \
 	-lintl -liberty $(LIBGNU)
 CLIBS = $(SIM) $(READLINE) $(OPCODES) $(BFD) $(INTL) $(LIBIBERTY) $(LIBDECNUMBER) \
-	$(XM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) @LIBS@ \
+	$(XM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) @LIBS@ @PYTHON_LIBS@ \
 	$(LIBEXPAT) \
 	$(LIBIBERTY) $(WIN32LIBS) $(LIBGNU)
 CDEPS = $(XM_CDEPS) $(NAT_CDEPS) $(SIM) $(BFD) $(READLINE_DEPS) \
diff --git a/gdb/configure b/gdb/configure
index 5cee400..2540f8b 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -659,6 +659,8 @@ TARGET_SYSTEM_ROOT
 CONFIG_LDFLAGS
 RDYNAMIC
 ALLOCA
+PYTHON_LIBS
+PYTHON_CPPFLAGS
 PYTHON_CFLAGS
 python_prog_path
 LTLIBEXPAT
@@ -10633,26 +10635,16 @@ fi
       fi
     fi
   else
-    # Fall back to gdb 7.0/7.1 behaviour.
-    if test -z ${python_prefix}; then
-      python_includes=
-      python_libs=
-    else
-      python_includes="-I${python_prefix}/include"
-      python_libs="-L${python_prefix}/lib"
-    fi
+    # We do not have a python executable we can use to determine where
+    # to find the Python headers and libs.  We cannot guess the include
+    # path from the python_prefix either, because that include path
+    # depends on the Python version.  So, there is nothing much we can
+    # do except assume that the compiler will be able to find those files.
+    python_includes=
+    python_libs=
     have_python_config=no
   fi
 
-  # Having "/pythonX.Y" in the include path is awkward.
-  # All those python headers get bubbled up to the top inviting lots
-  # of random collisions.  GDB originally didn't use python-config to
-  # find the compilation parameters and includes "pythonX.Y/" in the
-  # path of the, umm, include file.  So strip away this part of the
-  # output of python-config --includes.
-  python_includes=`echo "${python_includes} " \
-                        | sed -e 's,/python[0-9]*[.][0-9]* , ,g'`
-
   # If we have python-config, only try the configuration it provides.
   # Otherwise fallback on the old way of trying different versions of
   # python in turn.
@@ -10677,7 +10669,7 @@ $as_echo_n "checking for ${version}... " >&6; }
   found_usable_python=no
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
-#include "${version}/Python.h"
+#include "Python.h"
 int
 main ()
 {
@@ -10689,12 +10681,13 @@ _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
   have_libpython=${version}
                   found_usable_python=yes
-else
-  CPPFLAGS=$save_CPPFLAGS
-                  LIBS=$save_LIBS
+                  PYTHON_CPPFLAGS=$new_CPPFLAGS
+                  PYTHON_LIBS=$new_LIBS
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
+  CPPFLAGS=$save_CPPFLAGS
+  LIBS=$save_LIBS
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${found_usable_python}" >&5
 $as_echo "${found_usable_python}" >&6; }
 
@@ -10719,7 +10712,7 @@ $as_echo_n "checking for ${version}... " >&6; }
   found_usable_python=no
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
-#include "${version}/Python.h"
+#include "Python.h"
 int
 main ()
 {
@@ -10731,12 +10724,13 @@ _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
   have_libpython=${version}
                   found_usable_python=yes
-else
-  CPPFLAGS=$save_CPPFLAGS
-                  LIBS=$save_LIBS
+                  PYTHON_CPPFLAGS=$new_CPPFLAGS
+                  PYTHON_LIBS=$new_LIBS
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
+  CPPFLAGS=$save_CPPFLAGS
+  LIBS=$save_LIBS
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${found_usable_python}" >&5
 $as_echo "${found_usable_python}" >&6; }
 
@@ -10756,7 +10750,7 @@ $as_echo_n "checking for ${version}... " >&6; }
   found_usable_python=no
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
-#include "${version}/Python.h"
+#include "Python.h"
 int
 main ()
 {
@@ -10768,12 +10762,13 @@ _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
   have_libpython=${version}
                   found_usable_python=yes
-else
-  CPPFLAGS=$save_CPPFLAGS
-                  LIBS=$save_LIBS
+                  PYTHON_CPPFLAGS=$new_CPPFLAGS
+                  PYTHON_LIBS=$new_LIBS
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
+  CPPFLAGS=$save_CPPFLAGS
+  LIBS=$save_LIBS
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${found_usable_python}" >&5
 $as_echo "${found_usable_python}" >&6; }
 
@@ -10793,7 +10788,7 @@ $as_echo_n "checking for ${version}... " >&6; }
   found_usable_python=no
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
-#include "${version}/Python.h"
+#include "Python.h"
 int
 main ()
 {
@@ -10805,12 +10800,13 @@ _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
   have_libpython=${version}
                   found_usable_python=yes
-else
-  CPPFLAGS=$save_CPPFLAGS
-                  LIBS=$save_LIBS
+                  PYTHON_CPPFLAGS=$new_CPPFLAGS
+                  PYTHON_LIBS=$new_LIBS
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
+  CPPFLAGS=$save_CPPFLAGS
+  LIBS=$save_LIBS
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${found_usable_python}" >&5
 $as_echo "${found_usable_python}" >&6; }
 
@@ -10830,7 +10826,7 @@ $as_echo_n "checking for ${version}... " >&6; }
   found_usable_python=no
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
-#include "${version}/Python.h"
+#include "Python.h"
 int
 main ()
 {
@@ -10842,12 +10838,13 @@ _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
   have_libpython=${version}
                   found_usable_python=yes
-else
-  CPPFLAGS=$save_CPPFLAGS
-                  LIBS=$save_LIBS
+                  PYTHON_CPPFLAGS=$new_CPPFLAGS
+                  PYTHON_LIBS=$new_LIBS
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
+  CPPFLAGS=$save_CPPFLAGS
+  LIBS=$save_LIBS
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${found_usable_python}" >&5
 $as_echo "${found_usable_python}" >&6; }
 
@@ -10988,6 +10985,8 @@ else
 fi
 
 
+
+
 # ------------------------- #
 # Checks for header files.  #
 # ------------------------- #
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 4be35bc..afb7314 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -610,12 +610,14 @@ AC_DEFUN([AC_TRY_LIBPYTHON],
   CPPFLAGS="$CPPFLAGS $new_CPPFLAGS"
   LIBS="$LIBS $new_LIBS"
   found_usable_python=no
-  AC_LINK_IFELSE(AC_LANG_PROGRAM([[#include "${version}/Python.h"]],
+  AC_LINK_IFELSE(AC_LANG_PROGRAM([[#include "Python.h"]],
                                  [[Py_Initialize ();]]),
                  [have_libpython_var=${version}
-                  found_usable_python=yes],
-                 [CPPFLAGS=$save_CPPFLAGS
-                  LIBS=$save_LIBS])
+                  found_usable_python=yes
+                  PYTHON_CPPFLAGS=$new_CPPFLAGS
+                  PYTHON_LIBS=$new_LIBS])
+  CPPFLAGS=$save_CPPFLAGS
+  LIBS=$save_LIBS
   AC_MSG_RESULT([${found_usable_python}])
 ])
 
@@ -744,26 +746,16 @@ else
       fi
     fi
   else
-    # Fall back to gdb 7.0/7.1 behaviour.
-    if test -z ${python_prefix}; then
-      python_includes=
-      python_libs=
-    else
-      python_includes="-I${python_prefix}/include"
-      python_libs="-L${python_prefix}/lib"
-    fi
+    # We do not have a python executable we can use to determine where
+    # to find the Python headers and libs.  We cannot guess the include
+    # path from the python_prefix either, because that include path
+    # depends on the Python version.  So, there is nothing much we can
+    # do except assume that the compiler will be able to find those files.
+    python_includes=
+    python_libs=
     have_python_config=no
   fi
 
-  # Having "/pythonX.Y" in the include path is awkward.
-  # All those python headers get bubbled up to the top inviting lots
-  # of random collisions.  GDB originally didn't use python-config to
-  # find the compilation parameters and includes "pythonX.Y/" in the
-  # path of the, umm, include file.  So strip away this part of the
-  # output of python-config --includes.
-  python_includes=`echo "${python_includes} " \
-                        | sed -e 's,/python[[0-9]]*[[.]][[0-9]]* , ,g'`
-
   # If we have python-config, only try the configuration it provides.
   # Otherwise fallback on the old way of trying different versions of
   # python in turn.
@@ -881,6 +873,8 @@ else
 	python/py-prettyprint.c python/py-auto-load.c"
 fi
 AC_SUBST(PYTHON_CFLAGS)
+AC_SUBST(PYTHON_CPPFLAGS)
+AC_SUBST(PYTHON_LIBS)
 
 # ------------------------- #
 # Checks for header files.  #
diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index 80d0763..a572003 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -41,25 +41,17 @@
    around technique as above.  */
 #undef _FILE_OFFSET_BITS
 
+/* Include the Python header files using angle brackets rather than
+   double quotes.  On case-insensitive filesystems, this prevents us
+   from including our python/python.h header file.  */
+#include <Python.h>
+#include <frameobject.h>
 #if HAVE_LIBPYTHON2_4
-#include "python2.4/Python.h"
-#include "python2.4/frameobject.h"
 /* Py_ssize_t is not defined until 2.5.
    Logical type for Py_ssize_t is Py_intptr_t, but that fails in 64-bit
    compilation due to several apparent mistakes in python2.4 API, so we
    use 'int' instead.  */
 typedef int Py_ssize_t;
-#elif HAVE_LIBPYTHON2_5
-#include "python2.5/Python.h"
-#include "python2.5/frameobject.h"
-#elif HAVE_LIBPYTHON2_6
-#include "python2.6/Python.h"
-#include "python2.6/frameobject.h"
-#elif HAVE_LIBPYTHON2_7
-#include "python2.7/Python.h"
-#include "python2.7/frameobject.h"
-#else
-#error "Unable to find usable Python.h"
 #endif
 
 /* If Python.h does not define WITH_THREAD, then the various
-- 
1.7.1

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFA 1/2] do not use python<version> subdir when including Python .h file
  2011-01-23  0:14 ` [RFA 1/2] do not use python<version> subdir when including Python .h file Joel Brobecker
@ 2011-01-28 11:24   ` Tom Tromey
  2011-01-28 14:37     ` Joel Brobecker
  2011-01-31  4:44   ` Joel Brobecker
  1 sibling, 1 reply; 9+ messages in thread
From: Tom Tromey @ 2011-01-28 11:24 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> One last change is the fact that we are now including Python.h
Joel> and all other Python include headers using angle brackets rather
Joel> than double-quotes.  This fixes a problem on case-insensitive
Joel> systems where #include "Python.h" causes our gdb/python/python.h
Joel> header to be included instead of Python's <Python.h> header.

How does this work when srcdir != builddir?  In that case isn't our
python.h found only via a -I option?  Thus causing a clash?

Anyway, this patch looks fine to me.  If the above is a non-issue, go
for it.  If it is an issue, I didn't mind your earlier patch to rename
it to gdb-python.h.

Tom

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFA 2/2] allow building GDB with Python support on MinGW
  2011-01-22 23:45 ` [RFA 2/2] allow building GDB with Python support on MinGW Joel Brobecker
@ 2011-01-28 11:32   ` Tom Tromey
  2011-01-31  4:50     ` Joel Brobecker
  0 siblings, 1 reply; 9+ messages in thread
From: Tom Tromey @ 2011-01-28 11:32 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> This makes several adjustements to the configure python-config.py
Joel> scripts to deal with the differences between a Unix install of Python
Joel> and a Windows install of Python (as downloaded from the Python website).

FWIW, it seems reasonable to me, though I think you should self-approve
on the basis that you know more about python-config.py than anybody else :-)

Tom

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFA 1/2] do not use python<version> subdir when including Python .h file
  2011-01-28 11:24   ` Tom Tromey
@ 2011-01-28 14:37     ` Joel Brobecker
  2011-01-28 14:54       ` Tom Tromey
  0 siblings, 1 reply; 9+ messages in thread
From: Joel Brobecker @ 2011-01-28 14:37 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches

Thanks for looking at the patches, Tom.

> Joel> One last change is the fact that we are now including Python.h
> Joel> and all other Python include headers using angle brackets rather
> Joel> than double-quotes.  This fixes a problem on case-insensitive
> Joel> systems where #include "Python.h" causes our gdb/python/python.h
> Joel> header to be included instead of Python's <Python.h> header.
> 
> How does this work when srcdir != builddir?  In that case isn't our
> python.h found only via a -I option?  Thus causing a clash?

I discovered while working on this that there is actually no -I option
for the gdb/python directory (I thought that we did and I was looking
at that in an attempt to eliminate it).  Files from the gdb/ directory
include our python headers using #include "python/python-internal.h",
while files in the gdb/python/ directory include them more directly
using #include "python-internal.h". 

I do my builds out of tree almost exclusively, I can't remember when
the last time was that I built in-tree. I know that it works in this
case, but I should probably double-check in-tree as well.  I will do
that as soon as I come back from my vacation :-).

-- 
Joel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFA 1/2] do not use python<version> subdir when including Python .h file
  2011-01-28 14:37     ` Joel Brobecker
@ 2011-01-28 14:54       ` Tom Tromey
  0 siblings, 0 replies; 9+ messages in thread
From: Tom Tromey @ 2011-01-28 14:54 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

Tom> How does this work when srcdir != builddir?  In that case isn't our
Tom> python.h found only via a -I option?  Thus causing a clash?

Joel> I discovered while working on this that there is actually no -I option
Joel> for the gdb/python directory (I thought that we did and I was looking
Joel> at that in an attempt to eliminate it).  Files from the gdb/ directory
Joel> include our python headers using #include "python/python-internal.h",
Joel> while files in the gdb/python/ directory include them more directly
Joel> using #include "python-internal.h". 

Aha, that's what I was forgetting.
Thanks.

Tom

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFA 1/2] do not use python<version> subdir when including Python .h file
  2011-01-23  0:14 ` [RFA 1/2] do not use python<version> subdir when including Python .h file Joel Brobecker
  2011-01-28 11:24   ` Tom Tromey
@ 2011-01-31  4:44   ` Joel Brobecker
  1 sibling, 0 replies; 9+ messages in thread
From: Joel Brobecker @ 2011-01-31  4:44 UTC (permalink / raw)
  To: gdb-patches

> gdb/ChangeLog:
> 
> 	* configure.ac: Remove fallback behavior for building
> 	against Python.  Remove tweaking of Python include path.
> 	Add PYTHON_CPPFLAGS and PYTHON_LIBS substitution.
> 	(AC_TRY_LIBPYTHON):  Adjust program used in linking test.
> 	If link is successful, set PYTHON_CPPFLAGS and PYTHON_LIBS.
> 	Always restore CPPFLAGS and LIBS after linking test.
> 	* configure: Regenerated.
> 	* Makefile.in (INTERNAL_CPPFLAGS): Add @PYTHON_CPPFLAGS@.
> 	(INSTALLED_LIBS, CLIBS): Add @PYTHON_LIBS@.
> 	* python/python-internal.h: Adjust includes of Python .h files.

Patch checked in, after confirming that the build works both
in and out of tree...

-- 
Joel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFA 2/2] allow building GDB with Python support on MinGW
  2011-01-28 11:32   ` Tom Tromey
@ 2011-01-31  4:50     ` Joel Brobecker
  0 siblings, 0 replies; 9+ messages in thread
From: Joel Brobecker @ 2011-01-31  4:50 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches

>> gdb/ChangeLog:
>> 
>>         * configure.ac: Add handling of Python distribution on Windows.
>>         * python-config.py: If the LIBS, SYSLIBS, LIBPL and/or LINKFORSHARED
>>         sysconfig variables are not defined, then do not use them.
>>         On Windows, if LIBPL is not defined, then use prefix + '/libs'
>>         instead.  On Windows, return all paths using forward-slashes
>>         rather than backslashes.

> FWIW, it seems reasonable to me, though I think you should self-approve
> on the basis that you know more about python-config.py than anybody else :-)

Thanks! I appreciate the review, though, because of the changes in
configure.ac...

Checked in.

-- 
Joel

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2011-01-31  4:44 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-22 23:45 Allow building GDB with Python support on Windows/MinGW Joel Brobecker
2011-01-22 23:45 ` [RFA 2/2] allow building GDB with Python support on MinGW Joel Brobecker
2011-01-28 11:32   ` Tom Tromey
2011-01-31  4:50     ` Joel Brobecker
2011-01-23  0:14 ` [RFA 1/2] do not use python<version> subdir when including Python .h file Joel Brobecker
2011-01-28 11:24   ` Tom Tromey
2011-01-28 14:37     ` Joel Brobecker
2011-01-28 14:54       ` Tom Tromey
2011-01-31  4:44   ` Joel Brobecker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).