[GRASS-dev] fixes for Windows

GRASS GRASS developer
1

Colin,

With help from Glynn Clements, I was able to fix the bug that prevented NVIZ for TclTk from running from the wxPython menu. I also added the TclTk digitizer to the menu. So now Windows users will have easy access to 3D rendering and digitizing (without requiring that msys be loaded) until the wxPython equivalents can be implemented in Windows.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

2

Michael,
Great to have that bug finally fixed. Helmut should be putting another
release together in the next week so it will be in there.

-Colin

On Tue, Dec 15, 2009 at 1:49 AM, Michael Barton <michael.barton@asu.edu> wrote:

Colin,

With help from Glynn Clements, I was able to fix the bug that prevented NVIZ
for TclTk from running from the wxPython menu. I also added the TclTk
digitizer to the menu. So now Windows users will have easy access to 3D
rendering and digitizing (without requiring that msys be loaded) until the
wxPython equivalents can be implemented in Windows.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

3

Michael Barton wrote:

With help from Glynn Clements, I was able to fix the bug that
prevented NVIZ for TclTk from running from the wxPython menu. I also
added the TclTk digitizer to the menu. So now Windows users will have
easy access to 3D rendering and digitizing (without requiring that
msys be loaded) until the wxPython equivalents can be implemented in
Windows.

FWIW, with a bit of hacking, I managed to get vdigit and nviz to
compile with MinGW, but both fail at the linking step with a
"ld.exe has encountered a problem ..." dialog. That's as far as I have
got so far.

Issues:

1. The lack of python-config and wx-config scripts. I just created
scripts which give the right answers for my system.

2. The setup.py build system passes the Platform.make settings to gcc
without going through the shell, which means that the MSys-style
pathnames don't get translated to valid Windows pathnames.

I got around this by inserting the following into setup.py:

  mounts = [('/c/', 'c:/'),
      ('/usr/', 'c:/msys/1.0/'),
      ('/', 'c:/msys/1.0/')]
  
  def from_msys(d):
      for src, dst in mounts:
    if d.startswith(src):
        d = dst + d[len(src):]
        break
      d = d.replace('/', '\\')
      return d
  
  inc_dirs = map(from_msys, inc_dirs)
  lib_dirs = map(from_msys, lib_dirs)

Cygwin has the "cygpath" utility for this, but I couldn't find
anything similar for MSys.

3. Python.h defines HAVE_PUTENV and HAVE_FTIME, which causes the
preprocessor to emit "... redefined" warnings. These are only
warnings, but AC_CHECK_HEADERS fails if anything is written to stderr.

4. setup.py doesn't consider enough variables, e.g. CPPFLAGS and
INCLUDE_DIRS aren't used. But then the whole thing with trying to
parse the *.make files is broken (e.g. "make ... VAR=val" doesn't
work).

5. The definition of PACKAGE needs the backslashes, i.e.:

  macros = [('PACKAGE', '\\"grasslibs\\"')]

(but this might break other platforms).

BTW, vdigit uses _(...) but doesn't include glocale.h, so this will
use wxWidgets' _(...) macro from <wx/intl.h>, not GRASS'.

6. A couple of minor bugs:

vdigit/digit.cpp expects _CPPRTTI to be defined if _WIN32 is defined,
but this should only be done for MSVC.

vdigit/driver.cpp uses getpid() but doesn't include <unistd.h>.

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

4

Thanks Glynn.

I hope that someone is able to help you with this. Sounds like it is getting close.

Michael

On Dec 15, 2009, at 8:01 PM, Glynn Clements wrote:

Michael Barton wrote:

With help from Glynn Clements, I was able to fix the bug that
prevented NVIZ for TclTk from running from the wxPython menu. I also
added the TclTk digitizer to the menu. So now Windows users will have
easy access to 3D rendering and digitizing (without requiring that
msys be loaded) until the wxPython equivalents can be implemented in
Windows.

FWIW, with a bit of hacking, I managed to get vdigit and nviz to
compile with MinGW, but both fail at the linking step with a
"ld.exe has encountered a problem ..." dialog. That's as far as I have
got so far.

Issues:

1. The lack of python-config and wx-config scripts. I just created
scripts which give the right answers for my system.

2. The setup.py build system passes the Platform.make settings to gcc
without going through the shell, which means that the MSys-style
pathnames don't get translated to valid Windows pathnames.

I got around this by inserting the following into setup.py:

  mounts = [('/c/', 'c:/'),
      ('/usr/', 'c:/msys/1.0/'),
      ('/', 'c:/msys/1.0/')]
  
  def from_msys(d):
      for src, dst in mounts:
    if d.startswith(src):
        d = dst + d[len(src):]
        break
      d = d.replace('/', '\\')
      return d
  
  inc_dirs = map(from_msys, inc_dirs)
  lib_dirs = map(from_msys, lib_dirs)

Cygwin has the "cygpath" utility for this, but I couldn't find
anything similar for MSys.

3. Python.h defines HAVE_PUTENV and HAVE_FTIME, which causes the
preprocessor to emit "... redefined" warnings. These are only
warnings, but AC_CHECK_HEADERS fails if anything is written to stderr.

4. setup.py doesn't consider enough variables, e.g. CPPFLAGS and
INCLUDE_DIRS aren't used. But then the whole thing with trying to
parse the *.make files is broken (e.g. "make ... VAR=val" doesn't
work).

5. The definition of PACKAGE needs the backslashes, i.e.:

  macros = [('PACKAGE', '\\"grasslibs\\"')]

(but this might break other platforms).

BTW, vdigit uses _(...) but doesn't include glocale.h, so this will
use wxWidgets' _(...) macro from <wx/intl.h>, not GRASS'.

6. A couple of minor bugs:

vdigit/digit.cpp expects _CPPRTTI to be defined if _WIN32 is defined,
but this should only be done for MSVC.

vdigit/driver.cpp uses getpid() but doesn't include <unistd.h>.

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

5

Hi,

2009/12/16 Glynn Clements <glynn@gclements.plus.com>:

[...]

5. The definition of PACKAGE needs the backslashes, i.e.:

   macros = \[\(&#39;PACKAGE&#39;, &#39;\\\\&quot;grasslibs\\\\&quot;&#39;\)\]

(but this might break other platforms).

Then I am getting (GNU/Linux)

<command-line>: warning: missing terminating " character

Could this be avoided?

BTW, vdigit uses _(...) but doesn't include glocale.h, so this will
use wxWidgets' _(...) macro from <wx/intl.h>, not GRASS'.

6. A couple of minor bugs:

vdigit/digit.cpp expects _CPPRTTI to be defined if _WIN32 is defined,
but this should only be done for MSVC.

vdigit/driver.cpp uses getpid() but doesn't include <unistd.h>.

Should be fixed in r40030.

Martin

6

Martin Landa wrote:

> 5. The definition of PACKAGE needs the backslashes, i.e.:
>
> macros = [('PACKAGE', '\\"grasslibs\\"')]
>
> (but this might break other platforms).

Then I am getting (GNU/Linux)

<command-line>: warning: missing terminating " character

I thought that something like that might happen. If the existing code
is correct for Linux, a changed version probably wouldn't be.

Could this be avoided?

  if sys.platform == "win32":
      package = '\\"grasslibs\\"'
  else:
      package = '"grasslibs"'
  macros = [('PACKAGE', package)]

?

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

7

Hi,

2009/12/17 Glynn Clements <glynn@gclements.plus.com>:

[...]

Could this be avoided?

   if sys\.platform == &quot;win32&quot;:
       package = &#39;\\\\&quot;grasslibs\\\\&quot;&#39;
   else:
       package = &#39;&quot;grasslibs&quot;&#39;
   macros = \[\(&#39;PACKAGE&#39;, package\)\]

sure, done in r40036.

Martin

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