grass: tries to load wx despite --disable-wxwidgets

[mojca (Mojca Miklavec)]

When building grass without support for wxWidgets, there are nevertheless errors:

DEBUG: Executing command line:  cd "/opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.3" && ./configure --prefix=/opt/local --with-fftw-includes=/opt/local/include --with-fftw-libs=/opt/local/lib --with-freetype --with-freetype-includes=/opt/local/include/freetype2 --with-freetype-libs=/opt/local/lib --with-gdal=/opt/local/bin/gdal-config --with-jpeg-includes=/opt/local/include --with-jpeg-libs=/opt/local/lib --with-motif --with-motif-includes=/opt/local/include --with-motif-libs=/opt/local/lib --with-png-includes=/opt/local/include --with-png-libs=/opt/local/lib --with-proj-includes=/opt/local/lib/proj47/include --with-proj-libs=/opt/local/lib/proj47/lib --with-proj-share=/opt/local/lib/proj47/share/proj --with-tcltk-includes=/opt/local/include --with-tcltk-libs=/opt/local/lib --with-cxx --with-x --without-postgres --disable-python --disable-wxwidgets --enable-largefile --with-cairo --with-cairo-includes=/opt/local/include/cairo --with-cairo-libs=/opt/local/lib --with-blas --with-lapack --with-readline --with-readline-includes=/opt/local/include/readline --with-readline-libs=/opt/local/lib --with-regex-includes=/usr/include --with-regex-lib=/usr/lib 
...
checking whether to use Python... no
checking whether to use wxWidgets... no
...
GRASS is now configured for:  x86_64-apple-darwin11.4.2

  Source directory:            /opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.3
  Build directory:             /opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.3
  Installation directory:      ${prefix}/share/grass-6.4.3
  Startup script in directory: ${exec_prefix}/bin
  C compiler:                  /usr/bin/llvm-gcc-4.2 -pipe -Os -arch x86_64 
  C++ compiler:                /usr/bin/llvm-g++-4.2 -pipe -Os -arch x86_64
  Building shared libraries:   yes
  64bit support:               no
  OpenGL platform:             X11

  MacOSX application:         no
  MacOSX architectures:       
  MacOSX SDK:                 

  Tcl/Tk NVIZ:                yes

  BLAS support:               yes
  C++ support:                yes
  Cairo support:              yes
  DWG support:                no
  FFMPEG support:             no
  FFTW support:               yes
  FreeType support:           yes
  GDAL support:               yes
  GEOS support:               no
  GLw support:                no
  LAPACK support:             yes
  Large File support (LFS):   yes
  Motif support:              yes
  MySQL support:              no
  NLS support:                no
  ODBC support:               no
  OGR support:                yes
  OpenGL support:             yes
  PNG support:                yes
  PostgreSQL support:         no
  Python support:             no
  Readline support:           yes
  SQLite support:             no
  Tcl/Tk support:             yes
  wxWidgets support:          no
  TIFF support:               yes
  X11 support:                yes

The error is:

Traceback (most recent call last):
  File "core/menudata.py", line 39, in <module>
    import wx
ImportError: No module named wx
make[2]: *** [menustrings.py] Error 1

See ​https://build.macports.org/builders/buildports-lion-x86_64/builds/13829. This probably has to be reported upstream.

Another problem on this build seems to be a completely weird:

Error: /opt/local/include/GL/gl.h:109: Syntax error at '\n'
Error: /opt/local/include/GL/gl.h:112: Syntax error at '\n'

as well as:

Error: Can't open display: 
../../tools/mkhtml.sh xganim ; mkdir -p /opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.3/dist.x86_64-apple-darwin11.4.2/docs/html ; /usr/bin/install -c  -m 644 xganim.tmp.html /opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.3/dist.x86_64-apple-darwin11.4.2/docs/html/xganim.html ; for file in  *.png *.jpg ; do head -n 1 $file | grep '^#!' > /dev/null ; if [ $? -ne 0 ] ; then /usr/bin/install -c  -m 644 $file /opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.3/dist.x86_64-apple-darwin11.4.2/docs/html ; fi done 2> /dev/null ; true

I would suggest making wxwidgets the default variant anyway (and maybe figure out how to disable X11).

See also #36904.

[manuel.deljesuspe@…]

Cc Me!

[dbevans (David B. Evans)]

Unrelated fix for +ffmpeg build problem committed in r111848.

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

I made a local copy of this portfile to work on it and all of a sudden started running into this issue... I hadn't been running into it before so I wonder which change I made might've accidentally reintroduced it...

[petrrr]

Cc Me!

[cooljeanius (Eric Gallager)]

After looking at the portfile some more, some questions that might be relevant to this issue:

• Why is the wxWidgets PortGroup used outside of the +wxWidgets variant?
• Why is wxWidgets.use set to wxPython-3.0 outside of the +wxPython variant?

[mojca (Mojca Miklavec)]

In r116076 I changed the port in such a way that it depends on wxWidgets no matter what. If anyone really needs the software without any GUI, we can look at this again. It's probably still worth submitting a bug report upstream if anyone cares enough, but in it's current form it doesn't affect the port in MacPorts any longer.

Just to answer the last questions:

Replying to egall@…:

• Why is the wxWidgets PortGroup used outside of the +wxWidgets variant?

Because it doesn't matter. The PortGroup itself doesn't do any modifications and doesn't change the port in any way. One needs to explicitly use

wxWidgets.use wxWidgets-2.8

to restrict the set of platforms or throw an error when incompatible platform is used for example. And dependencies need to be added explicitly.

• Why is wxWidgets.use set to wxPython-3.0 outside of the +wxPython variant?

Same as above: because it doesn't matter until one actually uses

depends_lib-append port:${wxWidgets.port}

but I changed that last part in r116076 where two different versions are supported.

[Veence (Vincent)]

I think it would be nice to have an option to build without the GUI. Grass functions can now be used inside QGis through the Sextant extension. Typically, since I have QGis installed, I don't care about Grass UI, but I'm still interested in using the various algorithms the software provides.

[mojca (Mojca Miklavec)]

Can you please open a new ticket with something like "Allow building grass without GUI" and CC everyone from this ticket then?

• Please also explain the situation with dependencies on Python and wxPython. (Whether that has to be optional as well.)
• Do you agree to build GUI by default?
• Is a new variant +gui needed then? (Otherwise, I don't see how one could install grass with GUI by default without forcing any wxWidgets version on user and yet allow disabling wxWidgets.)
• Please include a proposal how to change the variants.
• If possible, please test and report where it goes wrong if you change the port your way, install grass without gui (but with wxWidgets and wxPython installed on the system), then uninstall both wxWidgets and wxPython and try to run grass in your mode.
• If possible, please explain how to test grass without the gui.

I don't know how to use grass, with or without the GUI, but I was trying to clean up the mess from wxWidgets and I was aware that grass simply doesn't work with wxWidgets 3.0 yet.

I was thinking of creating a subport with the latest version from SVN or from weekly snapshots.

[Veence (Vincent)]

I can propose you the addition of a +console variant that disables all gui and builds only the modules. I upload a possible portfile. By the way, this portfile fixes a name collision in r.terraflow, after which grass builds fine with clang (but I haven't tried to build with the GUI)

[Veence (Vincent)]

Portfile with a +console option and some fix for Clang

[mojca (Mojca Miklavec)]

Weird. Even without your patch I'm unable to reproduce a compile error with clang on 10.7. I would like to report the problem upstream if possible.

[mojca (Mojca Miklavec)]

I opened this ticket: ​http://trac.osgeo.org/grass/ticket/2170

[mojca (Mojca Miklavec)]

And committed the patch for r.terraflow in r116164. (Doing it step-by-step.)