[GRASS5] Win32 compile with cygnus ...

[Andreas Lange]

Hi 2 all,

i will answer all the recent mails on this topic in one mail, i am in a
hurry today.

- netpbm:
I tried to recompile the netpbm 9.8 source with cygnus. Does not work. 
The makefile target does not build the libraries and headers, only the
binaries, so that it is of no value for the build of r.in.png/r.out.png. 
The binary tarball i found on the net does _not_ contain the header
files.
So no luck to compile this on Win32.
To put this right: the r.in.png/r.out.png do _not_ use the
code/binaries/libraries from the netpbm utils as far as i could see (can
Alex Shevlakov please comment on this?). They only need the header file,
so that we could check this file(s) in to src/include if there are no
licensing issues. There is no using of the common format approach James
Cameron describes in his mail, so no dependency on netpbm tools. But i
think that if you do graphics with script programming you should have
the netpbm tools installed. 

- Perl/g.html2man (to Michel Wuerz)
The cygwin setup consists of nearly all the GNU tools (bash, sed, gawk,
m4 etc etc.), because the autotools (automake, autoconfig, autoheader
etc.) depend on them. I think that perl is not installed by default
because of size limits. On NT i have installed a NT Perl build, because
it is integrated with Win (registry manipulation etc.). I personally
have no problem with perl as a prerequisite, but i think that only the
man page generation does not justify that. The man program is included
in cygwin. Perhaps there is a Perl2c converter? I only know of awk2perl
and sed2perl converters. 
The other option i described was that the html2man conversion is done
centrally and the man files checked in to the CVS repository. The
generation/compiling mechanism makes sense IMHO only if you prepare
something that is taylored to the target architecture and / or changed
so frequently that is must be rebuild locally. Both is not the case with
the man pages. 

- float.h header file
I fear i mixed this up with something else. float.h should be ok. 
Is there any solution to the problem of the missing values.h file ?
I think that manually creation of this file is no viable solution.

- configure.in
I tried to add the XDR/rpclib seek that Mike Thomas advised and some
other things to configure.in, but i can't build the configure script
(autoconf 2.13 installed). 
If someone hacked something directly into configure this is very bad. 
The following should be added to configure.in: 
AC_PROG_YACC, and replace bison -y with @YACC@ in the header file.
XDR: this library is named librpclib on win -> rpclib to add.
some checks for sys/ipc.h and sys/msg.h for the IPC message queue
system.
more library checks.
And the library and include directives in the header file should be
standardized somehow. Some LIBNAME = do not mean the library, but the
library path. Very confusing. 
Perhaps someone more autoconf-savy can do this.

- G_* functions.
Sorry, i did not check which functions are available. 
But generally i think that using functions from the gis library will
enhance portablility. But this is not much an issue today, with c
standards. The whole thing came IMHO from the pre-ansi time when the
string functions on BSD and SYS V have been very different.  
I did not look at the implementation of the functions and some functions
may be unnecessary at all. One advantage of the implementation of string
functions with the gis library is that you don't need to bother about
including the header files. 
Before we decide anything on those functions we should look where they
are used. 

I changed the problematic re-definition of malloc and realloc in one of
the libraries, should compile now. 


- some more problems with the cygwin build:

One program in the src/fonts/for_grass directory (splitfont, but the
problem could be with font_2_bin that writes font.bin) does not work on
Win32, i suspect that it is a problem with text/binary mode difference
on windows. But the program uses open/creat/write, not fopen/fwrite, so
i don't know how to fix this for windows. 

The cygnus system lacks "more", so that nearly all programs that use
system("more") to display something do not work. Creating a link (ln -s
/bin/less /bin/more) does not help much, because you have to press "q"
to exit. 

The ipc.h and msg.h files are in local/include, so some include
directive must be set on cygwin.

I want to underline that i started the cygwin compile thing only because
i had the impression that we need to solve the windows problems before
we publish the stable version. Otherwise Windwos users will curse on
GRASS and on Unix software generally. I hope to get the X11R6 for
Windows on CD to compile the X windows part. 
The windows port still needs a lot of user land testing. 

cu,

Andreas
 


 
 
-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'