[GRASS-user] GRASS-7svn: Specify wxPython Version

   I have two wxPython versions installed: -2.8.12.1 for one application (I
forget which one requires this version) and -3.0.2.0 for applications I
develop.

   In an application here the main module needs include these lines:

import wxversion
wxversion.select('3.0.2.0')
import wx

   Because I don't want to change source code each time I suck down the
latest from the subversion repository I'd like to specify this in the
configuration file. However, while I see the option for specifying where to
find wxWidgets I have not found how to specify the wxPython version, and
this causes a fatal error when compiling.

Please advise,

Rich

On Jul 26, 2015 1:56 PM, “Rich Shepard” <rshepard@appl-ecosys.com> wrote:

I have two wxPython versions installed: -2.8.12.1 for one application (I
forget which one requires this version) and -3.0.2.0 for applications I
develop.

In an application here the main module needs include these lines:

import wxversion
wxversion.select(‘3.0.2.0’)
import wx

Because I don’t want to change source code each time I suck down the
latest from the subversion repository I’d like to specify this in the
configuration file. However, while I see the option for specifying where to
find wxWidgets I have not found how to specify the wxPython version, and
this causes a fatal error when compiling.

There is nothing like that in the configure. I don’t have currently any good advice, but you don’t have to modify the code after every svn up if your local changes don’t cause a conflict. If you think there is something which should be changed in the code to make it easier, let us know

Anna

Please advise,

Rich


grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On Mon, 27 Jul 2015, Anna Petrášová wrote:

There is nothing like that in the configure.

Anna,

   I did not see any, either.

I don't have currently any good advice, but you don't have to modify the
code after every svn up if your local changes don't cause a conflict. If
you think there is something which should be changed in the code to make
it easier, let us know

   Should I grep the source tree for 'import wx' or is there a single file in
which it is imported? Haven't looked at GRASS source in years.

Thanks,

Rich

On Mon, 27 Jul 2015, Rich Shepard wrote:

Should I grep the source tree for 'import wx' or is there a single file in
which it is imported?

   Sigh, As expected, it's in every .py file. I see an awk script in the near
future.

Thanks, Anna,

Rich

maybe something like

–with-wxwidgets=/usr/local/lib/wxPython-3.0.2.0/bin/wx-config \

during configure?

Carlos

···

On Mon, Jul 27, 2015 at 9:55 AM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Mon, 27 Jul 2015, Rich Shepard wrote:

Should I grep the source tree for ‘import wx’ or is there a single file in
which it is imported?

Sigh, As expected, it’s in every .py file. I see an awk script in the near
future.

Thanks, Anna,

Rich


grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil

  • Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/0000-0001-5073-5572


Can’t stop the signal.

On Mon, 27 Jul 2015, Carlos Grohmann wrote:

maybe something like
--with-wxwidgets=/usr/local/lib/wxPython-3.0.2.0/bin/wx-config \
during configure?

Carlos,

   The configuration file contains the line
--with-wxwidgets=/usr/bin/wx-config
and wx-config has a way of specifying a version using a mask:

# get_mask [ _hash ]
# Construct a config filename mask from a pseudo-hash of component variable
s.
# The optional argument is the prefix of the hash to use. If not specified
# this will return a mask derived from the command line options that were u
sed.
get_mask()
{
     [ $# -gt 0 ] || set m

     case "$m_ourversion" in
         2.9)
             is29orlater=1
             ;;
         2.*)
             # there is no 2.10 so currently everything else is <= 2.8
             is29orlater=0
             ;;
         *)
             # 3.x and later "is29orlater" too
             is29orlater=1
             ;;
     esac

     # use 2.8 or 2.9 version of the mask: the difference is the presence of
     # debug type in pre-2.9
     if [ $is29orlater = 0 ]; then
         eval echo
"\${$1_host:+\$$1_host-}\${$1_toolkit}\${$1_widgetset}-\${$1_chartype}-\${$1_debugtype}\${$1_linkage:+-\$$1_linkage}-\${$1_version}\${$1_flavour}"
     else
         eval echo
"\${$1_host:+\$$1_host-}\${$1_toolkit}\${$1_widgetset}-\${$1_chartype}\${$1_linkage:+-\$$1_linkage}-\${$1_version}\${$1_flavour}"
     fi
}

   So there ought to be a way to pass 'is29orlater=1' on the configuration
line, but I've no idea how to do this.

Thanks,

Rich

Rich,

If I just run wx-config, I get this:

wx-config [–prefix[=DIR]] [–exec-prefix[=DIR]] [–release] [–version-full]
[–list] [–selected-config] [–host=HOST] [–toolkit=TOOLKIT]
[–universal[=yes|no]] [–unicode[=yes|no]] [–static[=yes|no]]
[–debug[=yes|no]] [–version[=VERSION]] [–basename] [–cc] [–cxx]
[–cppflags [base]] [–cxxflags [base]] [–cflags]
[–rescomp] [–linkdeps] [–ld] [–utility=UTIL]
[–libs [LIBS…]] [–optional-libs [LIBS…]]

wx-config returns information about the wxWidgets libraries available on
your system. It may be used to retrieve the information required to build
applications using these libraries using --cppflags, --cxxflags, --cflags,
and --libs options. And you may query the properties of this configuration
using --query-{host,toolkit,widgetset,chartype,debugtype,version,linkage}.

NOTE: Usage of --debug and --query-debugtype are only relevant if you
have any versions prior to 2.9 installed and use the --version option to
select an earlier version.

If multiple builds of wxWidgets are available, you can use the options
–prefix, --host, --toolkit, --unicode, --static, --universal or --version
to select from them. The --selected-config option shows the name of the
current configuration and --list shows available alternatives which match
specified criteria. The --utility option returns the correct version of
UTIL to use with the selected build. The --linkdeps option returns only
static libraries for your makefile link rule dependencies.

The LIBS arguments (comma or space separated) may be used to specify the
wxWidgets libraries that you wish to use. The “std” label may be used to
import all libraries that would be used by default if none were specified
explicitly, e.g. wx-config --libs core,base. The “all” label may be used
to import all libraries that have been compiled which are shown in the
list below. The --optional-libs parameter should be followed by a list
of libs that should be linked to, but only if they are available.

Available libraries in this build are:
xrc webview stc richtext ribbon propgrid aui gl media html adv core xml net base

Trying the option listed in the third paragraph:

wx-config --selected-config
osx_cocoa-unicode-3.0

wx-config --list
Default config is osx_cocoa-unicode-3.0

Default config will be used for output

wx-config --version

3.0.1

So maybe one of those could be used at configure?

best

Carlos

···

On Mon, Jul 27, 2015 at 1:00 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Mon, 27 Jul 2015, Carlos Grohmann wrote:

maybe something like
–with-wxwidgets=/usr/local/lib/wxPython-3.0.2.0/bin/wx-config
during configure?

Carlos,

The configuration file contains the line
–with-wxwidgets=/usr/bin/wx-config
and wx-config has a way of specifying a version using a mask:

get_mask [ _hash ]

Construct a config filename mask from a pseudo-hash of component variable

s.

The optional argument is the prefix of the hash to use. If not specified

this will return a mask derived from the command line options that were u

sed.
get_mask()
{
[ $# -gt 0 ] || set m

case “$m_ourversion” in
2.9)
is29orlater=1
;;
2.*)

there is no 2.10 so currently everything else is <= 2.8

is29orlater=0
;;
*)

3.x and later “is29orlater” too

is29orlater=1
;;
esac

use 2.8 or 2.9 version of the mask: the difference is the presence of

debug type in pre-2.9

if [ $is29orlater = 0 ]; then
eval echo
“${$1_host:+$$1_host-}${$1_toolkit}${$1_widgetset}-${$1_chartype}-${$1_debugtype}${$1_linkage:±$$1_linkage}-${$1_version}${$1_flavour}”
else
eval echo
“${$1_host:+$$1_host-}${$1_toolkit}${$1_widgetset}-${$1_chartype}${$1_linkage:±$$1_linkage}-${$1_version}${$1_flavour}”
fi
}

So there ought to be a way to pass ‘is29orlater=1’ on the configuration
line, but I’ve no idea how to do this.

Thanks,

Rich


grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil

  • Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/0000-0001-5073-5572


Can’t stop the signal.

Anna, Carlos, et al.:

   Found the solution; perhaps this will help others in the future.

   Add these lines to wxgui.py:
import wxversion
wxversion.select('3.0.2.0')

just above the line
import wx

   That's the only place needed. I suspect that wxgui.py is not changed that
often so this is easy to maintain.

Rich

On Mon, 27 Jul 2015, Rich Shepard wrote:

Found the solution; perhaps this will help others in the future.
Add these lines to wxgui.py:

   Turns out to be a lot more complicated. It's always the tplot module that
fails, so I added the wxversion.select() to all *.py modules. Makes no
difference. Still fails to find wxPython and it looks in a hard-coded
directory, where it should find wxPython-2.8.12.2 if not -3.0.2.0.
wxGTK-2.8.12-i486-3 is install, too.

make[1]: Entering directory
/home/rshepard/GIS/GRASS/grass-7.0svn/gui/wxpython/tplot'
GISRC=/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/demolocation/.grassrc71
GISBASE=/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu
PATH="/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/bin:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/bin:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/scripts:$PATH"
PYTHONPATH="/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/etc/python:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/gui/wxpython:$PYTHONPATH"
LD_LIBRARY_PATH="/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/bin:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/scripts:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/lib:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/lib:/usr/lib/qt/lib:/usr/lib/qt/lib:"
LC_ALL=C
/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/scripts/g.gui.tplot
--html-description < /dev/null | grep -v '</body>\|</html>' >
-- g.gui.tplot.tmp.html
ERROR: wxGUI requires wxPython.
/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so: symbol
_ZTV14wxGraphicsPath, version WXU_2.8 not defined in file
libwx_gtk2u_core-2.8.so.0 with link time reference
make[1]: *** [g.gui.tplot.tmp.html] Error 1
rm g.gui.tplot.tmp.html
make[1]: Leaving directory
/home/rshepard/GIS/GRASS/grass-7.0svn/gui/wxpython/tplot'
make: *** [guiscript] Error 2

Rich

Rich Shepard wrote:

   I have two wxPython versions installed: -2.8.12.1 for one application (I
forget which one requires this version) and -3.0.2.0 for applications I
develop.

   In an application here the main module needs include these lines:

import wxversion
wxversion.select('3.0.2.0')
import wx

   Because I don't want to change source code each time I suck down the
latest from the subversion repository I'd like to specify this in the
configuration file. However, while I see the option for specifying where to
find wxWidgets I have not found how to specify the wxPython version, and
this causes a fatal error when compiling.

The wxPython version is handled by the CheckForWx() function in
gui/wxpython/core/globalvar.py. The default is taken from the
GRASS_WXVERSION environment variable if that's defined, otherwise it
allows wxversion to select the version, subject to the constraint that
the version must be at least 2.8.10.1.

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

On Mon, 27 Jul 2015, Glynn Clements wrote:

The wxPython version is handled by the CheckForWx() function in
gui/wxpython/core/globalvar.py. The default is taken from the
GRASS_WXVERSION environment variable if that's defined, otherwise it
allows wxversion to select the version, subject to the constraint that the
version must be at least 2.8.10.1.

Glynn,

   I see that wxversion checks for a version >=2.8.10.1. As both 2.8.12.1 and
3.0.2.0 are installed I would expect CheckForWx() to find one or the other.

   Where should I define GRASS_WXVERSION so globalvar.py finds it?
~/.bash_profile was not checked.

Thanks,

Rich

On Mon, 27 Jul 2015, Glynn Clements wrote:

The wxPython version is handled by the CheckForWx() function in
gui/wxpython/core/globalvar.py. The default is taken from the
GRASS_WXVERSION environment variable if that's defined, otherwise it
allows wxversion to select the version, subject to the constraint that the
version must be at least 2.8.10.1.

Glynn,

   The versions installed here are 2.8.12.1 and 3.0.2.0. I prefer to build
GRASS with the latter version. Having tried to specify the GRASS_WXVERSION
variable in various GRASS source files and exported from ~/.bash_profile
without successfully building tplot I would appreciate your suggestion where
that environment variable should be inserted.

Thanks,

Rich

Rich Shepard wrote:

> The wxPython version is handled by the CheckForWx() function in
> gui/wxpython/core/globalvar.py. The default is taken from the
> GRASS_WXVERSION environment variable if that's defined, otherwise it
> allows wxversion to select the version, subject to the constraint that the
> version must be at least 2.8.10.1.

Glynn,

   The versions installed here are 2.8.12.1 and 3.0.2.0. I prefer to build
GRASS with the latter version. Having tried to specify the GRASS_WXVERSION
variable in various GRASS source files and exported from ~/.bash_profile
without successfully building tplot I would appreciate your suggestion where
that environment variable should be inserted.

It's an environment variable. You can set environment variables within
an existing shell session with e.g.

  export GRASS_WXVERSION=2.8-gtk2-unicode

If you're using bash, you can set environment variables in
~/.bash_profile or ~/.bashrc or various other places, but those are
only read when starting a new shell (~/.bash_profile is only read when
starting a login shell); changing those file won't affect any existing
shell sessions.

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

On Thu, 30 Jul 2015, Glynn Clements wrote:

  export GRASS_WXVERSION=2.8-gtk2-unicode

Glynn,

   In ~/.bash_profile either:
   export GRASS_WXVERSION=wxGTK-2.8.12
or
   export GRASS_WXVERSION=wx-2.8-gtk2-unicode
and sourced.

   Both result in same error in:

/home/rshepard/GIS/GRASS/grass-7.0svn/gui/wxpython/tplot

   In the tplot subdirectory, running make:

ERROR: wxGUI requires wxPython.
/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so: symbol
_ZTV14wxGraphicsPath, version WXU_2.8 not defined in file
libwx_gtk2u_core-2.8.so.0 with link time reference
make[1]: *** [g.gui.tplot.tmp.html] Error 1
rm g.gui.tplot.tmp.html

   There were no build errors from the svn checkout 3 weeks ago; no python or
gtk packages updated since then.

   There seems to be an issue with the _gdi_.so shared library. I'll look for
an updated wxGTK2 or re-install the existing one.

   Your suggestions and advice also valuable.

Thanks,

Rich

On Thu, 30 Jul 2015, Rich Shepard wrote:

There were no build errors from the svn checkout 3 weeks ago; no python or
gtk packages updated since then.

   Actually, wxGTK was updated on 7 July. The last source updat and sucessful
build was the previous Friday, 3 July.

   Yesterday I re-built and re-installed wxGTK-2.8.12. Now I'm getting a
different error in tplot/; not that wxPython is required, but its version
must be >= 2.8.10 (which, of course, it is).

   Here are the full results of 'make' in the tplot subdirectory:

make
/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/docs/html/g.gui.tplot.html
make[1]: Entering directory `/home/rshepard/GIS/GRASS/grass-7.0svn/gui/wxpython/tplot'
GISRC=/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/demolocation/.grassrc71
GISBASE=/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu
PATH="/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/bin:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/bin:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/scripts:$PATH"
PYTHONPATH="/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/etc/python:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/gui/wxpython:$PYTHONPATH"
LD_LIBRARY_PATH="/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/bin:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/scripts:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/lib:/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/lib:/usr/lib/qt/lib:/usr/lib/qt/lib:"
LC_ALL=C
/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/scripts/g.gui.tplot --html-description < /dev/null | grep -v '</body>\|</html>' > -- g.gui.tplot.tmp.html
ERROR: wxGUI requires wxPython >= 2.8.10.1. invalid literal for int() with
base 10: 'wx'.
make[1]: *** [g.gui.tplot.tmp.html] Error 1
rm g.gui.tplot.tmp.html
make[1]: Leaving directory
/home/rshepard/GIS/GRASS/grass-7.0svn/gui/wxpython/tplot'
make: *** [guiscript] Error 2

   This situation appears related to generating some html. Does this help indentifying the source of my problem?

Rich

Rich Shepard wrote:

   This situation appears related to generating some html. Does this
   help indentifying the source of my problem?

The manual page for a module normally involves running the module with
the --html-description switch to get a list of its options. This
ensures that the options listed in the manual page always reflect
those actually supported by the module, without depending upon the
documentation being updated manually.

The g.gui.tplot script unconditionally imports core.giface, which
imports core.utils, which imports core.globalvar, which calls
CheckForWx() at the top-level. Consequently, any issues with the
wxPython installation will cause the script to fail even when run only
with e.g. the --help or --html-description options.

As for why the wxPython check fails, I would assume that it's
something specific to your particular installation.

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

On Sun, 2 Aug 2015, Glynn Clements wrote:

As for why the wxPython check fails, I would assume that it's something
specific to your particular installation.

Glynn,

   I suspected that the issue is related to having two wxPython versions
installed here. The build problem arose only after I installed 2.8.12 when I
discovered an application that required that version rather than 3.0.2.

   Because I've no current project requiring spatial analyses I'll drop the
issue. When I again need GRASS I'll find the cause of the problem when
building from the svn repository.

Thanks,

Rich