Heureka, kvetina place,
it is now possible to compile CVS HEAD GRASS 6 for Windows
on Linux using MinGW cross compiler. It is realy funny to run GRASS
modules from cmd.exe:
http://mpa.itc.it/radim/wingrass/cmd.exe.1.png
Here are step by step instructions:
http://mpa.itc.it/radim/wingrass/INSTALL
There is no user interface and not all modules compile/run,
the work is in progress. Vector modules from CVS do not compile
but with few changes I was able to compile and run also vectors but
without attributes (missing fork()).
This is possible thanks to previous work done by Roger Bivand
and Mike Thomas (others?) and all developers insisting
on ANSI C etc., especially Glynn Clements.
The recent work done by Javier Yebrin is not yet included and
I am going to include it into CVS in next days.
I hope that other developers will join the effort.
Radim
Hello Radim,
On Wed, 9 Nov 2005 18:52:32 +0100 Radim Blazek <radim.blazek@gmail.com>
wrote:
Heureka, kvetina place,
it is now possible to compile CVS HEAD GRASS 6 for Windows
on Linux using MinGW cross compiler. It is realy funny to run GRASS
modules from cmd.exe:
http://mpa.itc.it/radim/wingrass/cmd.exe.1.png
Here are step by step instructions:
http://mpa.itc.it/radim/wingrass/INSTALL
There is no user interface and not all modules compile/run,
the work is in progress. Vector modules from CVS do not compile
but with few changes I was able to compile and run also vectors but
without attributes (missing fork()).
This is possible thanks to previous work done by Roger Bivand
and Mike Thomas (others?) and all developers insisting
on ANSI C etc., especially Glynn Clements.
The recent work done by Javier Yebrin is not yet included and
I am going to include it into CVS in next days.
I hope that other developers will join the effort.
This is great news! Thanks for noticing the community about that
improvement.
Keep up the good work!
Best
Stephan
--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508
Radim Blazek wrote:
There is no user interface and not all modules compile/run,
the work is in progress. Vector modules from CVS do not compile
but with few changes I was able to compile and run also vectors but
without attributes (missing fork()).
This would be a good point to make a concerted effort to decide upon a
common interface for spawning child processes.
I have done some work on this, in lib/gis/spawn.c, but it is currently
untested, non-portable, and nothing uses it.
It would be useful if someone with access to a Windows development
environment could attempt to implement G_spawn[_ex] on Windows and let
me know which bits are problematic (signal handling?).
Let me know if you need any information about what those functions are
supposed to do.
--
Glynn Clements <glynn@gclements.plus.com>
On 11/12/05, Glynn Clements <glynn@gclements.plus.com> wrote:
Radim Blazek wrote:
> There is no user interface and not all modules compile/run,
> the work is in progress. Vector modules from CVS do not compile
> but with few changes I was able to compile and run also vectors but
> without attributes (missing fork()).
This would be a good point to make a concerted effort to decide upon a
common interface for spawning child processes.
For dbmi drivers I have done that already last Thursday using _spawnl.
Do you se any problems with?
I have done some work on this, in lib/gis/spawn.c, but it is currently
untested, non-portable, and nothing uses it.
It would be useful if someone with access to a Windows development
environment could attempt to implement G_spawn[_ex] on Windows and let
me know which bits are problematic (signal handling?).
Let me know if you need any information about what those functions are
supposed to do.
I have seen G_spawn but because it is not implemented for windows I just
started looking for something else.
_spawnl is described here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt__spawnl.2c_._wspawnl.asp
Would it be difficult to implement G_spawn using _spawnl?
Radim
Radim Blazek wrote:
> > There is no user interface and not all modules compile/run,
> > the work is in progress. Vector modules from CVS do not compile
> > but with few changes I was able to compile and run also vectors but
> > without attributes (missing fork()).
>
> This would be a good point to make a concerted effort to decide upon a
> common interface for spawning child processes.
For dbmi drivers I have done that already last Thursday using _spawnl.
Do you se any problems with?
It's insufficiently flexible for the general case, e.g. it doesn't
support redirection.
mon.start uses spawnl() for starting the driver, and it works OK
there.
> I have done some work on this, in lib/gis/spawn.c, but it is currently
> untested, non-portable, and nothing uses it.
>
> It would be useful if someone with access to a Windows development
> environment could attempt to implement G_spawn[_ex] on Windows and let
> me know which bits are problematic (signal handling?).
>
> Let me know if you need any information about what those functions are
> supposed to do.
I have seen G_spawn but because it is not implemented for windows I just
started looking for something else.
_spawnl is described here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt__spawnl.2c_._wspawnl.asp
Would it be difficult to implement G_spawn using _spawnl?
CreateProcess would probably be a better choice, as it provides more
functionality.
--
Glynn Clements <glynn@gclements.plus.com>
