[GRASS-dev] [GRASS GIS] #38: configure.in: wxwidgets and python checks

GDAL · February 5, 2008, 3:33pm

#38: configure.in: wxwidgets and python checks
---------------------+------------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor | Milestone: 6.4.0
Component: default | Version: svn-trunk
Keywords: |
---------------------+------------------------------------------------------
Hi,

I modified the configure script to support wxWidgets. It checks

  * if wx-config is presented
  * wxWidgets version (>=2.8.1 required)
  * check for wx/wxprec.h and wx/wxPython/pseudodc.h (wxPython required
too)

The patch also checks for Python.h header if --with-python is given.

This should solve compilation of wxGUI vdigit component

http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/vdigit/Makefile.in

Martin

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/38>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

GDAL · February 5, 2008, 3:34pm

#38: configure.in: wxwidgets and python checks
----------------------+-----------------------------------------------------
  Reporter: martinl | Owner: grass-dev@lists.osgeo.org
      Type: task | Status: new
  Priority: minor | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Changes (by martinl):

* type: defect => task

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/38#comment:1>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

GDAL · February 8, 2008, 3:26pm

#38: configure.in: wxwidgets and python checks
----------------------+-----------------------------------------------------
  Reporter: martinl | Owner: grass-dev@lists.osgeo.org
      Type: task | Status: new
  Priority: minor | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by martinl):

From ML by Glynn Clements:

You should probably use python-config to get this information.

I would suggest that --with-wxwidgets and --with-python take optional
arguments specifying the path to the wx-config and python-config
utilities respectively, in case they aren't in the path. --with-gdal
already behaves like this.

Also, is there any need to have vdigit/Makefile generated from
Makefile.in. Can the configuration settings not go into
Platform.make[.in]? vdigit/Makefile already includes Platform.make via
Lib.make.

> The patch checks for Python.h and include directory, it should work on
> Mac/Windows too.

The configure checks might work, but the hard-coded linking switches
and ".so" won't work. I suggest trying to mimic a normal library build
as closely as possible.

-----

Based on Glynn's notes I updated the patch (see configure_wx-1.diff)

Instead of --with-python=path/py-config is used --with-python=path/python.
Configure also checks for python-config.

{{{
--with-python[=path/python] enable Python support (python with path,
e.g. '--with-python=/usr/bin/python2.5', default: no)
--with-wxwidgets[=path/wx-config] enable wxWidgets support (wx-config
with path, e.g. '--with-wxwidgets=/usr/local/bin/wx-config', default: no)
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/38#comment:2>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

Glynn_Clements1 · February 8, 2008, 10:34pm

GRASS GIS wrote:

Based on Glynn's notes I updated the patch (see configure_wx-1.diff)

Instead of --with-python=path/py-config is used --with-python=path/python.
Configure also checks for python-config.

{{{
--with-python[=path/python] enable Python support (python with path,
e.g. '--with-python=/usr/bin/python2.5', default: no)
--with-wxwidgets[=path/wx-config] enable wxWidgets support (wx-config
with path, e.g. '--with-wxwidgets=/usr/local/bin/wx-config', default: no)
}}}

I think that you really should be using python-config rather than
trying to roll your own mechanism to achieve the same ends.

--
Glynn Clements <glynn@gclements.plus.com>

martinl · February 8, 2008, 9:49pm

Hi,

2008/2/8, Glynn Clements <glynn@gclements.plus.com>:

GRASS GIS wrote:

> Based on Glynn's notes I updated the patch (see configure_wx-1.diff)
>
> Instead of --with-python=path/py-config is used --with-python=path/python.
> Configure also checks for python-config.
>
> {{{
> --with-python[=path/python] enable Python support (python with path,
> e.g. '--with-python=/usr/bin/python2.5', default: no)
> --with-wxwidgets[=path/wx-config] enable wxWidgets support (wx-config
> with path, e.g. '--with-wxwidgets=/usr/local/bin/wx-config', default: no)
> }}}

I think that you really should be using python-config rather than
trying to roll your own mechanism to achieve the same ends.

python-config is used if available, see

AC_PATH_PROG(PY_CONFIG, python-config, no)

# With Python includes directory

  if test "$PY_CONFIG" = "no" ; then
    PYTHONINC="`$PYTHON -c ['import sys
includepy = \"%s/include/python%s\" % (sys.prefix, sys.version[:3])
if sys.version[0] > \"1\" or sys.version[2] > \"4\":
    libpl = \"%s/include/python%s\" % (sys.exec_prefix, sys.version[:3])
else:
    libpl = \"%s/'$PYLIB'/python%s/config\" % (sys.exec_prefix, sys.version[:3])
print \"-I%s -I%s\" % (includepy, libpl)'`]"
  else
    PYTHONINC=`"$PY_CONFIG" --cflags`
  fi
  LOC_CHECK_INCLUDES(Python.h,Python,$PYTHONINC)

I am not sure if to require python-config.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

Glynn_Clements1 · February 9, 2008, 9:14pm

Martin Landa wrote:

> > Based on Glynn's notes I updated the patch (see configure_wx-1.diff)
> >
> > Instead of --with-python=path/py-config is used --with-python=path/python.
> > Configure also checks for python-config.
> >
> > {{{
> > --with-python[=path/python] enable Python support (python with path,
> > e.g. '--with-python=/usr/bin/python2.5', default: no)
> > --with-wxwidgets[=path/wx-config] enable wxWidgets support (wx-config
> > with path, e.g. '--with-wxwidgets=/usr/local/bin/wx-config', default: no)
> > }}}
>
> I think that you really should be using python-config rather than
> trying to roll your own mechanism to achieve the same ends.

python-config is used if available, see

  AC_PATH_PROG(PY_CONFIG, python-config, no)

  # With Python includes directory

  if test "$PY_CONFIG" = "no" ; then
    PYTHONINC="`$PYTHON -c ['import sys
includepy = \"%s/include/python%s\" % (sys.prefix, sys.version[:3])
if sys.version[0] > \"1\" or sys.version[2] > \"4\":
    libpl = \"%s/include/python%s\" % (sys.exec_prefix, sys.version[:3])
else:
    libpl = \"%s/'$PYLIB'/python%s/config\" % (sys.exec_prefix, sys.version[:3])
print \"-I%s -I%s\" % (includepy, libpl)'`]"
  else
    PYTHONINC=`"$PY_CONFIG" --cflags`
  fi
  LOC_CHECK_INCLUDES(Python.h,Python,$PYTHONINC)

I am not sure if to require python-config.

I wouldn't assume that you can compile Python extensions without it.

For simple libraries, it's enough to know what the header and library
files are called and to let the user specify where they can be found.

For complex "subsystems", this is often inadequate. You may need any
number of additional libraries as well as specific compiler and linker
switches, many of which will be at least platform-dependent and
possibly worse (consider Gentoo, where everything gets built from
source with any number of user-selectable options).

E.g. on my system:

$ python-config --cflags
-I/usr/include/python2.4 -I/usr/include/python2.4 -fno-strict-aliasing -DNDEBUG

Okay, so --with-python-includes=-I/usr/include/python2.4 might
suffice, depending upon whether or not the code actually uses anything
which violates C aliasing rules and/or the extent to which the
compiler takes advantage of them (I presume the -fno-strict-aliasing
flag is there for a reason).

But that's on my system. There's no telling what additional flags it
might need on some other system.

--
Glynn Clements <glynn@gclements.plus.com>

Hamish · February 10, 2008, 12:04am

Glynn:

E.g. on my system:

$ python-config --cflags
-I/usr/include/python2.4 -I/usr/include/python2.4
-fno-strict-aliasing -DNDEBUG

Okay, so --with-python-includes=-I/usr/include/python2.4 might
suffice, depending upon whether or not the code actually uses
anything which violates C aliasing rules and/or the extent to which
the compiler takes advantage of them (I presume the
-fno-strict-aliasing flag is there for a reason).

But that's on my system. There's no telling what additional flags it
might need on some other system.

FWIW, on my system (Debian/stable) there is no python-config in sight.

$ locate python-config
$ apt-file search bin/python-config
$

nothin.
(apt-file searches all packages in the entire Debian(/stable) archive)
renamed?

Hamish

____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

martinl · February 10, 2008, 12:15am

Hi,

2008/2/10, Hamish <hamish_b@yahoo.com>:

Glynn:
> E.g. on my system:
>
> $ python-config --cflags
> -I/usr/include/python2.4 -I/usr/include/python2.4
> -fno-strict-aliasing -DNDEBUG
>
> Okay, so --with-python-includes=-I/usr/include/python2.4 might
> suffice, depending upon whether or not the code actually uses
> anything which violates C aliasing rules and/or the extent to which
> the compiler takes advantage of them (I presume the
> -fno-strict-aliasing flag is there for a reason).
>
> But that's on my system. There's no telling what additional flags it
> might need on some other system.

FWIW, on my system (Debian/stable) there is no python-config in sight.

$ locate python-config
$ apt-file search bin/python-config
$

nothin.
(apt-file searches all packages in the entire Debian(/stable) archive)
renamed?

python-config is part of *python-dev* package (only Debian
testing/unstable, it is not included in Etch). I don't know about
Mac/Windows Python distribution.

Martin
____________________________________________________________________________________

Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

martinl · February 10, 2008, 12:21am

Hi,

2008/2/10, Martin Landa <landa.martin@gmail.com>:

[skip]

> FWIW, on my system (Debian/stable) there is no python-config in sight.
>
> $ locate python-config
> $ apt-file search bin/python-config
> $
>
> nothin.
> (apt-file searches all packages in the entire Debian(/stable) archive)
> renamed?

python-config is part of *python-dev* package (only Debian
testing/unstable, it is not included in Etch). I don't know about
Mac/Windows Python distribution.

on Etch

python2.4-dev: usr/bin/python2.4-config
python2.5-dev: usr/bin/python2.5-config

I will upgrade configure to check also for python${PYVERSION}-config.

Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

William_Kyngesburye · February 10, 2008, 12:37am

On OSX, python-config is included in the python.org python framework, and in Apple's python 2.5 in Leopard. It is not in Apple's old python 2.3, but most users know to install python.org's python.

On Feb 9, 2008, at 6:15 PM, Martin Landa wrote:

Hi,

2008/2/10, Hamish <hamish_b@yahoo.com>:

Glynn:

E.g. on my system:

$ python-config --cflags
-I/usr/include/python2.4 -I/usr/include/python2.4
-fno-strict-aliasing -DNDEBUG

Okay, so --with-python-includes=-I/usr/include/python2.4 might
suffice, depending upon whether or not the code actually uses
anything which violates C aliasing rules and/or the extent to which
the compiler takes advantage of them (I presume the
-fno-strict-aliasing flag is there for a reason).

But that's on my system. There's no telling what additional flags it
might need on some other system.

FWIW, on my system (Debian/stable) there is no python-config in sight.

$ locate python-config
$ apt-file search bin/python-config
$

nothin.
(apt-file searches all packages in the entire Debian(/stable) archive)
renamed?

python-config is part of *python-dev* package (only Debian
testing/unstable, it is not included in Etch). I don't know about
Mac/Windows Python distribution.

Martin
____________________________________________________________________________________

Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

martinl · February 10, 2008, 12:50am

HI,

2008/2/9, Glynn Clements <glynn@gclements.plus.com>:
[snip]

I wouldn't assume that you can compile Python extensions without it.

For simple libraries, it's enough to know what the header and library
files are called and to let the user specify where they can be found.

For complex "subsystems", this is often inadequate. You may need any
number of additional libraries as well as specific compiler and linker
switches, many of which will be at least platform-dependent and
possibly worse (consider Gentoo, where everything gets built from
source with any number of user-selectable options).

E.g. on my system:

$ python-config --cflags
-I/usr/include/python2.4 -I/usr/include/python2.4 -fno-strict-aliasing -DNDEBUG

Okay, so --with-python-includes=-I/usr/include/python2.4 might
suffice, depending upon whether or not the code actually uses anything
which violates C aliasing rules and/or the extent to which the
compiler takes advantage of them (I presume the -fno-strict-aliasing
flag is there for a reason).

But that's on my system. There's no telling what additional flags it
might need on some other system.

thanks for clarification, I modified the patch to require
python-config (or python$PYVERSION-config), see

http://trac.osgeo.org/grass/attachment/ticket/38/configure_wx-2.diff

If no objections I will commit to SVN.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

Hamish · February 10, 2008, 12:54am

Martin Landa wrote:

> python-config is part of *python-dev* package (only Debian
> testing/unstable, it is not included in Etch). I don't know about
> Mac/Windows Python distribution.

on Etch

python2.4-dev: usr/bin/python2.4-config
python2.5-dev: usr/bin/python2.5-config

I will upgrade configure to check also for python${PYVERSION}-config.

Ah yes, thanks.

Hamish

____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Glynn_Clements1 · February 10, 2008, 6:31pm

Martin Landa wrote:

> > FWIW, on my system (Debian/stable) there is no python-config in sight.
> >
> > $ locate python-config
> > $ apt-file search bin/python-config
> > $
> >
> > nothin.
> > (apt-file searches all packages in the entire Debian(/stable) archive)
> > renamed?
>
> python-config is part of *python-dev* package (only Debian
> testing/unstable, it is not included in Etch). I don't know about
> Mac/Windows Python distribution.

And if you don't have python-dev, you won't be able to build python
extensions for more fundamental reasons than the lack of
python-config.

on Etch

python2.4-dev: usr/bin/python2.4-config
python2.5-dev: usr/bin/python2.5-config

[Does it create symlinks? Anything created by a post-install script
won't be visible from apt-search.]

In any case, that's why we need to allow e.g.
--with-python=python2.4-config

I will upgrade configure to check also for python${PYVERSION}-config.

Where are you going to get ${PYVERSION} from before you've located the
python-config program? If there is more than one version installed,
invoking "python" won't necessarily use the right version.

Resist the temptation to turn configure into an expert system. The
general policy is that any deviation from the obvious default has to
be explicitly specified by the user.

E.g. any headers which aren't in the system include path require the
corresponding --with-includes= switch, regardless of how common a
particular setting is.

--
Glynn Clements <glynn@gclements.plus.com>

martinl · February 10, 2008, 5:53pm

Hi,

2008/2/10, Glynn Clements <glynn@gclements.plus.com>:

> > > FWIW, on my system (Debian/stable) there is no python-config in sight.
> > >
> > > $ locate python-config
> > > $ apt-file search bin/python-config
> > > $
> > >
> > > nothin.
> > > (apt-file searches all packages in the entire Debian(/stable) archive)
> > > renamed?
> >
> > python-config is part of *python-dev* package (only Debian
> > testing/unstable, it is not included in Etch). I don't know about
> > Mac/Windows Python distribution.

And if you don't have python-dev, you won't be able to build python
extensions for more fundamental reasons than the lack of
python-config.

> on Etch
>
> python2.4-dev: usr/bin/python2.4-config
> python2.5-dev: usr/bin/python2.5-config

[Does it create symlinks? Anything created by a post-install script
won't be visible from apt-search.]

It is true for Debian testing/unstable not for Etch(stable). There is
no python-config.

In any case, that's why we need to allow e.g.
--with-python=python2.4-config

> I will upgrade configure to check also for python${PYVERSION}-config.

Where are you going to get ${PYVERSION} from before you've located the
python-config program? If there is more than one version installed,
invoking "python" won't necessarily use the right version.

Python version is determined from small python script(s).

1656 # find out python version
1657 AC_MSG_CHECKING(Python version)
1658 PYVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[:3]'`]
1659 PYMAJVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[:1]'`]
1660 PYMINVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[2:3]'`]
1661 AC_MSG_RESULT($PYVERSION)
1662 AC_SUBST(PYVERSION)

I didn't change this part of configure script.

The problem with python-config is that there is *no* version switch.

So how to determine python version using python-config?

You can currently run with --with-python=/usr/bin/python2.5 to force
using version 2.5.

Resist the temptation to turn configure into an expert system. The
general policy is that any deviation from the obvious default has to
be explicitly specified by the user.

E.g. any headers which aren't in the system include path require the
corresponding --with-includes= switch, regardless of how common a
particular setting is.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

Ivan_Shmakov1 · February 10, 2008, 8:24pm

Martin Landa <landa.martin@gmail.com> writes:

[...]

> Python version is determined from small python script(s).

[...]

> I didn't change this part of configure script.

> The problem with python-config is that there is *no* version
> switch.

> So how to determine python version using python-config?

> You can currently run with --with-python=/usr/bin/python2.5 to
> force using version 2.5.

BTW, there're some Python-related Autoconf code in Automake and
in the Autoconf Macro Archive, e. g.:

$ dpkg -S python.m4
autoconf-archive: /usr/share/autoconf-archive/ax_boost_python.m4
autoconf-archive: /usr/share/autoconf-archive/ax_python.m4
autoconf-archive: /usr/share/autoconf-archive/ax_with_python.m4
autoconf-archive: /usr/share/autoconf-archive/az_python.m4
automake: /usr/share/aclocal-1.10/python.m4
$

  At the first glance, `az_python.m4' seems to be the most
  suitable. Apparently, it doesn't depend on `python-config', but
  accesses the same configuration storage using the ways native to
  Python.

Is this check suitable for GRASS?

[...]

Glynn_Clements1 · February 11, 2008, 8:53pm

Martin Landa wrote:

> In any case, that's why we need to allow e.g.
> --with-python=python2.4-config
>
> > I will upgrade configure to check also for python${PYVERSION}-config.
>
> Where are you going to get ${PYVERSION} from before you've located the
> python-config program? If there is more than one version installed,
> invoking "python" won't necessarily use the right version.

Python version is determined from small python script(s).

1656 # find out python version
1657 AC_MSG_CHECKING(Python version)
1658 PYVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[:3]'`]
1659 PYMAJVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[:1]'`]
1660 PYMINVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[2:3]'`]
1661 AC_MSG_RESULT($PYVERSION)
1662 AC_SUBST(PYVERSION)

I didn't change this part of configure script.

The problem with python-config is that there is *no* version switch.

Usage: /usr/bin/python-config
[--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help]

So how to determine python version using python-config?

You can currently run with --with-python=/usr/bin/python2.5 to force
using version 2.5.

Each version of python should have its own python-config which
provides switches relevant to that version.

E.g. if you use --with-python=python2.4-config, you'll get the
switches for 2.4.

In any case, if there is more than one version on offer, it's
preferable to require the user to explicitly choose a version than to
silently choose one for them.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn_Clements1 · February 11, 2008, 9:01pm

Ivan Shmakov wrote:

> You can currently run with --with-python=/usr/bin/python2.5 to
> force using version 2.5.

  BTW, there're some Python-related Autoconf code in Automake and
  in the Autoconf Macro Archive, e. g.:

$ dpkg -S python.m4
autoconf-archive: /usr/share/autoconf-archive/ax_boost_python.m4
autoconf-archive: /usr/share/autoconf-archive/ax_python.m4
autoconf-archive: /usr/share/autoconf-archive/ax_with_python.m4
autoconf-archive: /usr/share/autoconf-archive/az_python.m4
automake: /usr/share/aclocal-1.10/python.m4
$

  At the first glance, `az_python.m4' seems to be the most
  suitable. Apparently, it doesn't depend on `python-config', but
  accesses the same configuration storage using the ways native to
  Python.

  Is this check suitable for GRASS?

Why use anything other than python-config? If some other mechanism
produces the same result, there's no benefit; if it produces a
different result, it's presumably wrong.

If there's a standardised way to do something, using any other
mechanism is usually a maintenance headache waiting to happen.

--
Glynn Clements <glynn@gclements.plus.com>

Ivan_Shmakov1 · February 12, 2008, 7:42am

Glynn Clements <glynn@gclements.plus.com> writes:

[...]

>> BTW, there're some Python-related Autoconf code in Automake and in
>> the Autoconf Macro Archive, e. g.:

[...]

>> At the first glance, `az_python.m4' seems to be the most suitable.
>> Apparently, it doesn't depend on `python-config', but accesses the
>> same configuration storage using the ways native to Python.

>> Is this check suitable for GRASS?

> Why use anything other than python-config? If some other mechanism
> produces the same result, there's no benefit; if it produces a
> different result, it's presumably wrong.

> If there's a standardised way to do something, using any other
> mechanism is usually a maintenance headache waiting to happen.

I guess that the use of `get_config_var('CFLAGSFORSHARED')' is
as standartised as the use of `python-config'.

  But my point is wider, should a different Autoconf check be
  implemented for every project using Python, or a single macro
  would suffice? And if the latter, wouldn't it be better to
  adopt the check from the Autoconf macro archive for GRASS?

Alternatively, the GRASS check for Python may be added to the
Autoconf macro archive.

martinl · February 12, 2008, 2:59pm

Hi,

2008/2/11, Glynn Clements <glynn@gclements.plus.com>:

Martin Landa wrote:
> > In any case, that's why we need to allow e.g.
> > --with-python=python2.4-config
> >
> > > I will upgrade configure to check also for python${PYVERSION}-config.
> >
> > Where are you going to get ${PYVERSION} from before you've located the
> > python-config program? If there is more than one version installed,
> > invoking "python" won't necessarily use the right version.
>
> Python version is determined from small python script(s).
>
> 1656 # find out python version
> 1657 AC_MSG_CHECKING(Python version)
> 1658 PYVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[:3]'`]
> 1659 PYMAJVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[:1]'`]
> 1660 PYMINVERSION=`$PYTHON_BIN -c ['import sys; print sys.version[2:3]'`]
> 1661 AC_MSG_RESULT($PYVERSION)
> 1662 AC_SUBST(PYVERSION)
>
> I didn't change this part of configure script.
>
> The problem with python-config is that there is *no* version switch.
>
> Usage: /usr/bin/python-config
> [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help]
>
> So how to determine python version using python-config?
>
> You can currently run with --with-python=/usr/bin/python2.5 to force
> using version 2.5.

Each version of python should have its own python-config which
provides switches relevant to that version.

E.g. if you use --with-python=python2.4-config, you'll get the
switches for 2.4.

In any case, if there is more than one version on offer, it's
preferable to require the user to explicitly choose a version than to
silently choose one for them.

The last version of patch [1] uses --with-python=[path/python-config]
approach. Since I am not autoconf guru I cannot comment Ivan's notes.

Martin

[1] http://trac.osgeo.org/grass/attachment/ticket/38/configure_wx-3.diff

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

martinl · February 14, 2008, 10:23pm

Hi,

2008/2/12, Martin Landa <landa.martin@gmail.com>:

[snip]

The last version of patch [1] uses --with-python=[path/python-config]
approach. Since I am not autoconf guru I cannot comment Ivan's notes.

[1] http://trac.osgeo.org/grass/attachment/ticket/38/configure_wx-3.diff

not sure, are there any objections to commit this patch to SVN?

Regards, Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *