[GRASS5] CygWIN: compilation of current CVS HEAD?

Hi,

today we tried to compile the current CVS HEAD on Win2K/Cygwin
and faced some strange problems happening in
src/CMD/generic/gmake.sh

We used
sh -x /usr/local/bin/gmake5
to see the problem.
Probably it is related to the latest change for .cc files?

Problem:
The 'sort -u' in row 285 says "file not found".

We are trying to recompile an existing and updated CVS HEAD
version (last compilation was some weeks ago, successful).

Perhaps someone else could try the latest CVS HEAD on his/her
cygwin to see if it is a local problem here?

Thanks,

Markus Neteler

Markus Neteler wrote:

today we tried to compile the current CVS HEAD on Win2K/Cygwin
and faced some strange problems happening in
src/CMD/generic/gmake.sh

We used
sh -x /usr/local/bin/gmake5
to see the problem.
Probably it is related to the latest change for .cc files?

Problem:
The 'sort -u' in row 285 says "file not found".

Is GNU "sort" installed? Does it appear first in the path?

Otherwise, you may end up running the DOS sort.exe, which will try to
sort the file called "-u", and complain.

--
Glynn Clements <glynn.clements@virgin.net>

On Thu, Feb 06, 2003 at 02:49:56AM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> today we tried to compile the current CVS HEAD on Win2K/Cygwin
> and faced some strange problems happening in
> src/CMD/generic/gmake.sh
>
> We used
> sh -x /usr/local/bin/gmake5
> to see the problem.
> Probably it is related to the latest change for .cc files?
>
> Problem:
> The 'sort -u' in row 285 says "file not found".

Is GNU "sort" installed? Does it appear first in the path?

Otherwise, you may end up running the DOS sort.exe, which will try to
sort the file called "-u", and complain.

This will be the reason - in parallel we found this solution

    sort | uniq |
is nicer than
    sort -u

Maybe the suggestion is more portable? It's not my machine, so I don't
know right now if there is a DOS 'uniq.exe'.

Markus

Markus Neteler wrote:

> > today we tried to compile the current CVS HEAD on Win2K/Cygwin
> > and faced some strange problems happening in
> > src/CMD/generic/gmake.sh
> >
> > We used
> > sh -x /usr/local/bin/gmake5
> > to see the problem.
> > Probably it is related to the latest change for .cc files?
> >
> > Problem:
> > The 'sort -u' in row 285 says "file not found".
>
> Is GNU "sort" installed? Does it appear first in the path?
>
> Otherwise, you may end up running the DOS sort.exe, which will try to
> sort the file called "-u", and complain.

This will be the reason - in parallel we found this solution

    sort | uniq |
is nicer than
    sort -u

Maybe the suggestion is more portable? It's not my machine, so I don't
know right now if there is a DOS 'uniq.exe'.

There isn't, so Cygwin's (i.e. GNU) "uniq" will get used instead.

In any case, if you have the DOS tools (e.g. C:\WINDOWS\COMMMAND) in
the search path ahead of Cygwin's /bin directory, all manner of things
could go wrong[1], so there isn't much point in changing gmake.sh to
work around one specific symptom.

[1] e.g. using DOS' find.exe instead of GNU find definitely won't
work.

--
Glynn Clements <glynn.clements@virgin.net>

On Thu, Feb 06, 2003 at 08:45:33AM +0000, Glynn Clements wrote:

Markus Neteler wrote:

[...]

> > Otherwise, you may end up running the DOS sort.exe, which will try to
> > sort the file called "-u", and complain.
>
> This will be the reason - in parallel we found this solution
>
> sort | uniq |
> is nicer than
> sort -u
>
> Maybe the suggestion is more portable? It's not my machine, so I don't
> know right now if there is a DOS 'uniq.exe'.

There isn't, so Cygwin's (i.e. GNU) "uniq" will get used instead.

In any case, if you have the DOS tools (e.g. C:\WINDOWS\COMMMAND) in
the search path ahead of Cygwin's /bin directory, all manner of things
could go wrong[1], so there isn't much point in changing gmake.sh to
work around one specific symptom.

[1] e.g. using DOS' find.exe instead of GNU find definitely won't
work.

Thanks for the clarification. So we'll check the PATH here which
we modified to get the R/GRASS interface working [1].

Markus

[1] If interested, see instructions here:
    http://grass.itc.it/statsgrass/grass_r_insthints.html
    The Windows related instructions are written from suggestions
    of several users.
    This page could be improved, suggestions are welcome.

Markus Neteler wrote:

Thanks for the clarification. So we'll check the PATH here which
we modified to get the R/GRASS interface working [1].

Markus

[1] If interested, see instructions here:
    http://grass.itc.it/statsgrass/grass_r_insthints.html

It says:

- To bypass Cygwin's path and make sure that MinGW and Perl are the first
   directories in the Cygwin path. So, one needs to modify the /etc/profile
   file AND any user defined resource file in their home directory
   (i.e. a ~/.bash_profile that needed updating too - don't know why but it
   does). If ~/.bash_profile is not present, make it a copy of /etc/profile.
   In /etc/profile change the PATH= definition so that $PATH comes first
   (per default it comes last). Something like
   PATH="$PATH:/usr....."

If you do this, don't expect typical Unix-ish programs (the ones for
which you installed Cygwin in the first place) to still work
afterwards. Cygwin's /bin (or /usr/bin, they're just aliases) needs to
come first, before any Windows/DOS stuff.

If, for whatever reason, R needs to have the Windows/DOS stuff come
first, then you need choose between having R work and having
everything else work.

If there exists a choice between Unix and Windows versions of R,
choosing the Unix version is likely to result in better compatibility
with GRASS.

This is the same issue faced by tcltkgrass (which requires Unix/X11
Tcl/Tk, not Windows Tcl/Tk) and NVIZ (which requires Unix/X11 versions
of both Tcl/Tk and OpenGL, not the Windows versions).

--
Glynn Clements <glynn.clements@virgin.net>

On Thu, 6 Feb 2003, Glynn Clements wrote:

Markus Neteler wrote:

> Thanks for the clarification. So we'll check the PATH here which
> we modified to get the R/GRASS interface working [1].
>
> Markus
>
> [1] If interested, see instructions here:
> http://grass.itc.it/statsgrass/grass_r_insthints.html

It says:

- To bypass Cygwin's path and make sure that MinGW and Perl are the first
   directories in the Cygwin path. So, one needs to modify the /etc/profile
   file AND any user defined resource file in their home directory
   (i.e. a ~/.bash_profile that needed updating too - don't know why but it
   does). If ~/.bash_profile is not present, make it a copy of /etc/profile.
   In /etc/profile change the PATH= definition so that $PATH comes first
   (per default it comes last). Something like
   PATH="$PATH:/usr....."

If you do this, don't expect typical Unix-ish programs (the ones for
which you installed Cygwin in the first place) to still work
afterwards. Cygwin's /bin (or /usr/bin, they're just aliases) needs to
come first, before any Windows/DOS stuff.

If, for whatever reason, R needs to have the Windows/DOS stuff come
first, then you need choose between having R work and having
everything else work.

No, it's not that. The R build train for Windows is *not* CygWin, but
MinGW, which the people/person making the port judged to be more stable.
Consequently, DLLs to be dynamically loaded into R *have* to be compiled
using MinGW gcc and friends. However, this path order is *only* needed for
installing the R/GRASS interface (and all other contributed packages
compiled from source - very rare, almost all are installed as binaries),
nothing in R otherwise should conflict with a regular PATH order with
CygWin /bin early. I suggest a script to re-order the PATH prior to and
then after making an R package installation from source.

If there exists a choice between Unix and Windows versions of R,
choosing the Unix version is likely to result in better compatibility
with GRASS.

R on Windows will not build under CygWin. On the Windows platform, MinGW
is the chosen build train, following which R runs natively. One can
complain that it ought to be CygWin, but the reaction is to invite the
complainer to become R Windows maintainer. I think everyone is very
grateful for the work the Windows maintainers do, and R is not going to
move to CygWin while they are in place.

This is the same issue faced by tcltkgrass (which requires Unix/X11
Tcl/Tk, not Windows Tcl/Tk) and NVIZ (which requires Unix/X11 versions
of both Tcl/Tk and OpenGL, not the Windows versions).

No, not the same issue. It's a design choice which can be got round when
an R source package needs to be installed on a Windows machine set up for
CygWin. One solution is to make a binary package of the R/GRASS interface
on some host machine, and have Windows users install that, rather than
from source.

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

Roger Bivand wrote:

> If there exists a choice between Unix and Windows versions of R,
> choosing the Unix version is likely to result in better compatibility
> with GRASS.

R on Windows will not build under CygWin. On the Windows platform, MinGW
is the chosen build train, following which R runs natively. One can
complain that it ought to be CygWin, but the reaction is to invite the
complainer to become R Windows maintainer.

I'm just pointing out that the only way to use GRASS on Windows is via
Cygwin. If R can't use Cygwin, and GRASS can only use Cygwin, that
suggests that the GRASS/R combination may be inherently problematic.

--
Glynn Clements <glynn.clements@virgin.net>

On Fri, 7 Feb 2003, Glynn Clements wrote:

Roger Bivand wrote:

> > If there exists a choice between Unix and Windows versions of R,
> > choosing the Unix version is likely to result in better compatibility
> > with GRASS.
>
> R on Windows will not build under CygWin. On the Windows platform, MinGW
> is the chosen build train, following which R runs natively. One can
> complain that it ought to be CygWin, but the reaction is to invite the
> complainer to become R Windows maintainer.

I'm just pointing out that the only way to use GRASS on Windows is via
Cygwin. If R can't use Cygwin, and GRASS can only use Cygwin, that
suggests that the GRASS/R combination may be inherently problematic.

If the CygWin gcc compiled lisgib.a makes other assumptions about its
environment (compile train setup etc.) than the MinGW compiled grassR.dll
to be dynamically loaded into R, yes, but experience (limited) so far
suggests that it is not a major issue. If there were major differences
between the two gcc header file trees, you would get unexpected and, yes,
problematic, results. R and its dlls will also use the underlying C
libraries of MinGW. But providing that the two gcc's present the same
API's to R and GRASS, experience (again limited) indicates that - against
my expectations - it does work. One advantage of the R package formalisms
is that the functions need to be able to run their examples to completion,
which they certainly wouldn't do if the two gcc's had diverged.

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no