Hi,
I am trying if I can use the source code for GRASS and compile in VC++ (Windows.) so that I can run from Windows platfrom without Cygwin. The desire is to run it just as a VC++ workspace.
Can any one please help me in ths regard.
Regards,
Arindam Nath.
MSEE, University of Texas at Arlington
On Tue, 2007-03-13 at 18:24 -0500, Arindam Nath wrote:
Hi,
I am trying if I can use the source code for GRASS and compile in VC++
(Windows.) so that I can run from Windows platfrom without Cygwin. The
desire is to run it just as a VC++ workspace.
Can any one please help me in ths regard.
GRASS uses a number of UNIX conventions that are not present in Windows.
Cygwin provides the majority of missing functionality.
Unfortunately, a native[1] Windows port would involve a rewrite of most
of the code. IMO, the only realistic approach is to emulate object
orientation so that each OS could provide low level hooks to generalize
the code sanely (this approach will not cluttering the code with
preprocessor macros, long branches, etc.).
It would be nice to provide a native Windows port, but I don't see this
happening anytime soon. There is too much code and not enough
entrenched developers to provide such Whiz-Bang features.
[1] Cygwin is *not* native Windows. WIN32 API *is*.
--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
AFAIK, GRASS 6.3 is 95% compilable natively on win, and running fine.
Only a few modules are not (yet) working.
Alternatively, current QGIS installs bring the power of GRASS to win.
pc
Brad Douglas ha scritto:
On Tue, 2007-03-13 at 18:24 -0500, Arindam Nath wrote:
Hi,
I am trying if I can use the source code for GRASS and compile in VC++
(Windows.) so that I can run from Windows platfrom without Cygwin. The
desire is to run it just as a VC++ workspace.
Can any one please help me in ths regard.GRASS uses a number of UNIX conventions that are not present in Windows.
Cygwin provides the majority of missing functionality.Unfortunately, a native[1] Windows port would involve a rewrite of most
of the code. IMO, the only realistic approach is to emulate object
orientation so that each OS could provide low level hooks to generalize
the code sanely (this approach will not cluttering the code with
preprocessor macros, long branches, etc.).It would be nice to provide a native Windows port, but I don't see this
happening anytime soon. There is too much code and not enough
entrenched developers to provide such Whiz-Bang features.[1] Cygwin is *not* native Windows. WIN32 API *is*.
- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF96VL/NedwLUzIr4RApQWAJ9d7TY18TDWSmKUGno9aKylCiOzPQCfQ1sH
rA1+D9Q3zx6Zh2lnkX86QEE=
=+HZm
-----END PGP SIGNATURE-----
Arindam Nath wrote:
I am trying if I can use the source code for GRASS and compile in VC++
(Windows.) so that I can run from Windows platfrom without Cygwin. The
desire is to run it just as a VC++ workspace.
Much of GRASS can run natively (without Cygwin) on Windows, but you
still need to use GNU make to compile it.
If you want to compile it using VC++, you would need to build the
workspace and project files yourself. As there are over 500 Makefiles,
that would be a lot of work.
Also, you would need to update the VC++ files yourself to keep them in
sync with GRASS; it's inconceivable that we would require GRASS
developers to keep those files in sync with the existing Makefiles.
--
Glynn Clements <glynn@gclements.plus.com>
Brad Douglas wrote:
> I am trying if I can use the source code for GRASS and compile in VC++
> (Windows.) so that I can run from Windows platfrom without Cygwin. The
> desire is to run it just as a VC++ workspace.
> Can any one please help me in ths regard.GRASS uses a number of UNIX conventions that are not present in Windows.
Cygwin provides the majority of missing functionality.Unfortunately, a native[1] Windows port would involve a rewrite of most
of the code. IMO, the only realistic approach is to emulate object
orientation so that each OS could provide low level hooks to generalize
the code sanely (this approach will not cluttering the code with
preprocessor macros, long branches, etc.).It would be nice to provide a native Windows port, but I don't see this
happening anytime soon. There is too much code and not enough
entrenched developers to provide such Whiz-Bang features.[1] Cygwin is *not* native Windows. WIN32 API *is*.
MSVCRT is also "native"; that's enough for most of GRASS.
The main thing which doesn't work natively is the display drivers,
along with the corresponding portion of the raster library. This
applies to both the PNG and X drivers; we even have an X11 emulation
library so that the rendering portion of XDRIVER can use native
Windows GDI functions instead of requiring an X server.
The main problems with using monitors are the use of Unix-domain
sockets, and the startup (the driver fork()s into the background once
it has initialised and is ready to accept connections; mon.start is
closely tied to this behaviour).
Direct rendering still works, and gis.m works with a native Tcl/Tk
implementation. The new v.digit should work, as will the Tcl/Tk
implementation of d.rast.edit. NVIZ also works.
Consequently, anything which won't work with direct rendering but
requires an actual monitor (i.e. anything using R_get_location_with_*)
won't work natively on Windows. This includes i.[v]points and
i.ortho.photo.
Programs which make "ancilliary" use of the mouse functions will work
but the features which use the mouse won't work. E.g. d.barscale will
compile and run using direct rendering, but the -m switch isn't
meaningful without a monitor.
--
Glynn Clements <glynn@gclements.plus.com>
Ok then there is no other option than to run in Linux… right!
I have downloaded the full source code (grass-6.2.1.tar.gz) from the site http://grass.itc.it/download/index.php .
I have also installed Cygwin as directed in http://grass.itc.it/grass62/binary/mswindows/
After decompression the file I am trying to compile the make file in Linux but it is showing compilation errors.
if [ 1 -eq 1 ] ; then make -C locale; fi
make[1]: Entering directory /home/a/ax/axn8170/grass-6.2.1/locale' ../include/Make/Module.make:31: warning: overriding commands for target @GRASS_HOME@/dist.@host@/bin’
…/include/Make/Grass.make:397: warning: ignoring old commands for target @GRASS_HOME@/dist.@host@/bin' ../include/Make/Module.make:36: warning: overriding commands for target @GRASS_HOME@/dist.@host@/etc’
…/include/Make/Grass.make:400: warning: ignoring old commands for target @GRASS_HOME@/dist.@host@/etc' /bin/sh: line 1: CC@: command not found make[1]: *** [@GRASS_HOME@/dist.@host@/bin] Error 127 make[1]: Leaving directory /home/a/ax/axn8170/grass- 6.2.1/locale’
make: *** [default] Error 2
I am not able to understand the error message.
Moreover,
When I start Cygwin and then start x-windows and the typing grass62, then it is unable to display the data. Please note that I have downloaded the sample dataset
slovakia and slovakia3D in the grass data folder.
Can you please give me a detailed step by step instruction for running grass from source code in Linux. I want to run the operations separately (like the raster3D, raster operations) so that I can make use of the existing functionality and add to those.
It will be appriciated if you can give me a step by step guide as to how this is possible. Expecting your cooperation.
Regards
Arindam
Hi Brad,
I am trying to compile the code available at http://grass.itc.it/download/index.php in Linux
But there is an error in compiling the makefile.
On 3/14/07, Brad Douglas <rez@touchofmadness.com > wrote:
On Tue, 2007-03-13 at 18:24 -0500, Arindam Nath wrote:
Hi,
I am trying if I can use the source code for GRASS and compile in VC++
(Windows.) so that I can run from Windows platfrom without Cygwin. The
desire is to run it just as a VC++ workspace.
Can any one please help me in ths regard.GRASS uses a number of UNIX conventions that are not present in Windows.
Cygwin provides the majority of missing functionality.Unfortunately, a native[1] Windows port would involve a rewrite of most
of the code. IMO, the only realistic approach is to emulate object
orientation so that each OS could provide low level hooks to generalize
the code sanely (this approach will not cluttering the code with
preprocessor macros, long branches, etc.).It would be nice to provide a native Windows port, but I don’t see this
happening anytime soon. There is too much code and not enough
entrenched developers to provide such Whiz-Bang features.[1] Cygwin is not native Windows. WIN32 API is.
–
Brad Douglas KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785