i am short of time right now, but i write to confirm that grass works
for me with the latest cygwin distribution (on W2K). But i am using
GRASS from the command line and with the StarNet XWin32 XServer.
If there is demand i can re-build GRASS with X and upload.
The problem you mention is very strange and i have no clue what it could
be. I think the best bet would be to wait for a new build and re-install
then.
Please check that you did install with the supplied installation script
"grass5install.sh". Please refer to the installation instruction: http://grass.itc.it/grass5/binary/windows_cygnus/cygwin_grass50bininstall.html.
The instruction is not completely in line with the recent changes in
cygwin and XFree86 for cygwin.
HTH,
Andreas
Alex Thorn wrote:
OK. I just subscribed to GRASSLIST. It doesn't look
like the address is the same as the one that you cced
this to, so I'm not sure whether I will get messages
from that list or be able to send to it.
On Mon, Dec 10, 2001 at 09:04:28AM +0100, Andreas Lange wrote:
Hi Mike, Hi Alex,
i am short of time right now, but i write to confirm that grass works
for me with the latest cygwin distribution (on W2K). But i am using
GRASS from the command line and with the StarNet XWin32 XServer.
and I can confirm that GRASS with native driver compiles
well on WIN98. The monitor opens and displays maps.
If there is demand i can re-build GRASS with X and upload.
What about following:
- we build the winGRASS without and driver as package1
- we put the X11 based XDRIVER in package2
- we put the libG11.dll based XDRIVER in package3
Users just download 1 && ( 2 || 3) and we don't waste too
much space by duplicating 99% of the packages (in case we
want to provide both display drivers).
What about following:
- we build the winGRASS without and driver as package1
- we put the X11 based XDRIVER in package2
- we put the libG11.dll based XDRIVER in package3
Users just download 1 && ( 2 || 3) and we don't waste too
much space by duplicating 99% of the packages (in case we
want to provide both display drivers).
at the first thought this seems to be a good idea. But i don't know if
some of the d.* modules and other parts are linked to the X libraries.
And we will have to provide some sort of installtion script or a
detailed installation instruction (for windows users?).
I decided to stick to the X11 based distribution. This does not mean
that i don't like the effort with the libG11.dll, but i don't have the
time to support the other version too.
NB: The cygwin installer was recently improved very much. I'll look if i
can build a cygwin installable version, which will make installation
very easy (one mouse click).
cu,
Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net
> What about following:
> - we build the winGRASS without and driver as package1
> - we put the X11 based XDRIVER in package2
> - we put the libG11.dll based XDRIVER in package3
>
> Users just download 1 && ( 2 || 3) and we don't waste too
> much space by duplicating 99% of the packages (in case we
> want to provide both display drivers).
at the first thought this seems to be a good idea. But i don't know if
some of the d.* modules and other parts are linked to the X libraries.
1. d.scale is linked against Xlib if it is present (for "d.scale -i").
2. xganim uses Motif, and hence Xt, Xext, Xlib.
3. The native XDRIVER uses Xlib, obviously.
4. That's all, according to "ldd $GISBASE/etc/bin/*/*".
And we will have to provide some sort of installtion script or a
detailed installation instruction (for windows users?).
I decided to stick to the X11 based distribution. This does not mean
that i don't like the effort with the libG11.dll, but i don't have the
time to support the other version too.
If there's to be an "official" binary release for Cygwin, it shouldn't
require X (unless there are significant problems with the G11
XDRIVER). "d.scale -i" certainly doesn't justify requiring X, and
xganim probably doesn't either.
at the first thought this seems to be a good idea. But i don't know if
some of the d.* modules and other parts are linked to the X libraries.
I think from memory that d.scale is the only outlier - this is not really a
problem top sort out.
And we will have to provide some sort of installtion script or a
detailed installation instruction (for windows users?).
I decided to stick to the X11 based distribution. This does not mean
that i don't like the effort with the libG11.dll, but i don't have the
time to support the other version too.
This is a reasonable approach. For the time being I could just put together
a native XDriver and associated modules as a small archive, with a script to
unpack over the main distribution, renaming the original files. Possibly a
second script to switch between the two.
I hope to be able to do this soon (barring school holiday unforeseen
commitments), as last night I got a flash of understanding of the native
xlib screen refresh and event handling. There is still lots of stuff to
clear up, but I now have some light to work by and the XDriver refreshes
itself so it looks lots nicer.
NB: The cygwin installer was recently improved very much. I'll look if i
can build a cygwin installable version, which will make installation
very easy (one mouse click).
> at the first thought this seems to be a good idea. But i don't know if
> some of the d.* modules and other parts are linked to the X libraries.
I think from memory that d.scale is the only outlier - this is not really a
problem top sort out.
> And we will have to provide some sort of installtion script or a
> detailed installation instruction (for windows users?).
>
> I decided to stick to the X11 based distribution. This does not mean
> that i don't like the effort with the libG11.dll, but i don't have the
> time to support the other version too.
This is a reasonable approach. For the time being I could just put together
a native XDriver and associated modules as a small archive, with a script to
unpack over the main distribution, renaming the original files. Possibly a
second script to switch between the two.
Another option is to keep separate names for the X11/G11 versions of
XDRIVER, and use the appropriate name in the etc/monitorcap entries.
You could even have entries for both drivers (e.g. "w0", "w1" etc for
the native version), although that would require changes to anything
which has "x0" etc hardcoded (e.g. tcltkgrass).
BTW: I've just installed Cygwin on my Windows partition, but I need to
free up some space (it's only 2Gb; it previously only existed for
playing games) and/or convert it to FAT32 before I can build GRASS.
Now I'm *really* starting to wish that the build process supported
separate source/object directories.
On Wed, Dec 12, 2001 at 02:47:49PM +0000, Glynn Clements wrote:
[...]
Now I'm *really* starting to wish that the build process supported
separate source/object directories.
Great - no longer alone I volunteer to help in setting up the
new directory structure. Also for the vector development it's necessary
to have the Core-GRASS isolated and a Makefile system supporting this.
In
grass51/notyetuploaded/new_makefile_system/grass.remake.tgz
Is a new Makefile system from Eric Mitchell, we may start from
that.
I volunteer to help in setting up the