[GRASS-dev] Re: [GRASS-SVN] r40881 - in grass/trunk: gui/wxpython/nviz gui/wxpython/vdigit lib/gis visualization/wximgview

GRASS GRASS developer
1

On Tue, Feb 9, 2010 at 3:28 AM, <svn_grass@osgeo.org> wrote:

Author: glynn
Date: 2010-02-08 21:28:10 -0500 (Mon, 08 Feb 2010)
New Revision: 40881

Modified:
grass/trunk/gui/wxpython/nviz/Makefile
grass/trunk/gui/wxpython/nviz/setup.py
grass/trunk/gui/wxpython/vdigit/Makefile
grass/trunk/gui/wxpython/vdigit/setup.py
grass/trunk/lib/gis/popen.c
grass/trunk/visualization/wximgview/main.cc
Log:
Windows fixes

Do these changes render the digitizer to be usable now?
A backport candidate?

Markus

2

Markus Neteler wrote:

On Tue, Feb 9, 2010 at 3:28 AM, <svn_grass@osgeo.org> wrote:
> Author: glynn
> Date: 2010-02-08 21:28:10 -0500 (Mon, 08 Feb 2010)
> New Revision: 40881
>
> Modified:
> grass/trunk/gui/wxpython/nviz/Makefile
> grass/trunk/gui/wxpython/nviz/setup.py
> grass/trunk/gui/wxpython/vdigit/Makefile
> grass/trunk/gui/wxpython/vdigit/setup.py
> grass/trunk/lib/gis/popen.c
> grass/trunk/visualization/wximgview/main.cc
> Log:
> Windows fixes

Do these changes render the digitizer to be usable now?

No. MinGW's gcc crashes when trying to link C++ programs. The above
changes simply mean that the modules get to the crash-on-link stage
rather than failing earlier with compile errors.

A backport candidate?

Only popen.c, but I have another change pending for that (G_pager()
still doesn't work, although I'm unclear on the reason).

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

3

On Wed, Feb 10, 2010 at 12:20 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

On Tue, Feb 9, 2010 at 3:28 AM, <svn_grass@osgeo.org> wrote:
> Author: glynn
> Date: 2010-02-08 21:28:10 -0500 (Mon, 08 Feb 2010)
> New Revision: 40881
>
> Modified:
> grass/trunk/gui/wxpython/nviz/Makefile
> grass/trunk/gui/wxpython/nviz/setup.py
> grass/trunk/gui/wxpython/vdigit/Makefile
> grass/trunk/gui/wxpython/vdigit/setup.py
> grass/trunk/lib/gis/popen.c
> grass/trunk/visualization/wximgview/main.cc
> Log:
> Windows fixes

Do these changes render the digitizer to be usable now?

No. MinGW's gcc crashes when trying to link C++ programs. The above
changes simply mean that the modules get to the crash-on-link stage
rather than failing earlier with compile errors.

A backport candidate?

Only popen.c, but I have another change pending for that (G_pager()
still doesn't work, although I'm unclear on the reason).

I am unsure about the popen.c backport since the 6.5 version
differs significantly from trunk. (same with the recent spaw.c
fixes).

Markus

4

Markus Neteler wrote:

>> > grass/trunk/gui/wxpython/nviz/Makefile
>> > grass/trunk/gui/wxpython/nviz/setup.py
>> > grass/trunk/gui/wxpython/vdigit/Makefile
>> > grass/trunk/gui/wxpython/vdigit/setup.py
>> > grass/trunk/lib/gis/popen.c
>> > grass/trunk/visualization/wximgview/main.cc
>> > Log:
>> > Windows fixes
>>
>> Do these changes render the digitizer to be usable now?
>
> No. MinGW's gcc crashes when trying to link C++ programs. The above
> changes simply mean that the modules get to the crash-on-link stage
> rather than failing earlier with compile errors.
>
>> A backport candidate?
>
> Only popen.c, but I have another change pending for that (G_pager()
> still doesn't work, although I'm unclear on the reason).

I am unsure about the popen.c backport since the 6.5 version
differs significantly from trunk. (same with the recent spaw.c
fixes).

Right; the popen.c replacement hasn't been back-ported (and probably
shouldn't be), so there's no point in back-porting fixes to it.

FWIW, popen.c should now be entirely unused in 6.5, and may as well be
removed. I replaced all occurrences of G_popen() with popen() in
r40834, and G_pclose() with pclose() in r40921, as G_popen() doesn't
work at all on Windows. These should be back-ported to 6.4 after
testing.

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

5

On Thu, Feb 11, 2010 at 2:16 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

...

I am unsure about the popen.c backport since the 6.5 version
differs significantly from trunk. (same with the recent spaw.c
fixes).

Right; the popen.c replacement hasn't been back-ported (and probably
shouldn't be), so there's no point in back-porting fixes to it.

FWIW, popen.c should now be entirely unused in 6.5, and may as well be
removed. I replaced all occurrences of G_popen() with popen() in
r40834, and G_pclose() with pclose() in r40921, as G_popen() doesn't
work at all on Windows.

I have done so to reduce the (file) noise.

These should be back-ported to 6.4 after testing.

-> still TODO.

Markus

6

Glynn:

> FWIW, popen.c should now be entirely unused in 6.5,
> and may as well be removed.

Markus:

I have done so to reduce the (file) noise.

mmmph, we have no idea what functions people depend on in their
personal modules. We don't guarantee API compatibility, but
still it is not very nice to dump long serving functions in the
final part of a version's life ...

Hamish

7

On Thu, Feb 11, 2010 at 12:10 PM, Hamish <hamish_b@yahoo.com> wrote:

Glynn:

> FWIW, popen.c should now be entirely unused in 6.5,
> and may as well be removed.

Markus:

I have done so to reduce the (file) noise.

mmmph, we have no idea what functions people depend on in their
personal modules. We don't guarantee API compatibility, but
still it is not very nice to dump long serving functions in the
final part of a version's life ...

Could G_popen() be made a wrapper to popen()?
(if it doesn't work on Windows, it is useful only to a fraction of
operating systems).

I have searched around in GDAL and QGIS for the presence of G_popen()
but did not find anything (except for complaints of non-portability). Checked
also koders.com.

Markus

8

Markus Neteler wrote:

> mmmph, we have no idea what functions people depend on in their
> personal modules. We don't guarantee API compatibility, but
> still it is not very nice to dump long serving functions in the
> final part of a version's life ...

Could G_popen() be made a wrapper to popen()?

It could.

OTOH, anyone who was using it could just define macros, e.g.:

  CFLAGS='-DG_popen=popen -DG_pclose=pclose' ./configure ...

(if it doesn't work on Windows, it is useful only to a fraction of
operating systems).

I have searched around in GDAL and QGIS for the presence of G_popen()
but did not find anything (except for complaints of non-portability). Checked
also koders.com.

G_popen() wasn't being used in GRASS outside of lib/gis. Everything
else used popen().

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