r.in.gdal [was Re: [GRASS5] STDS(DEM)2ASC and Possible Bug]

[Frank Warmerdam]

"Eric G . Miller" wrote:
> 2.  Re: r.in.gdal.  libgdal has several dependencies above what GRASS
> already relies on.  I think it would be a good inclusion, but I think we
> might have difficuly meeting all the dependency requirements.  I found
> it less than trivial to get libgeotiff compiled, for instance, since it
> wanted to live in a certain place with respect to libtiff sources and
> requires private headers.  I don't think it's [libgeotiff] ubiquitous
> enough to be able to rely on it (though it certainly is desirable).
> Perhaps there's some minimal set of requirements that would still
> preserve it's [r.in.gdal] utility?

Eric, 

There are various ways to build libgdal.  In this case I think I would build
it with pretty much all the dependencies, including libgeotiff, libpng, 
libjpeg, libtiff and so forth "built in".  While this doesn't factor well
in general, it should be fine when it is only being used by r.in.gdal. 

I will update r.in.gdal today to search the $GISBASE/lib directory for the
gdal shared library, and prepare a "fully built-in" libgdal.1.1.so suitable
for distribution with GRASS.  If there is sufficient interest I could do the
same for Solaris and IRIX. 

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

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