[gdal-dev] packaging gdal for debian

[Tom Parker]

Frank,

First off, your gdal/ogr/proj libraries are peachy-keen and I use them a
lot, I work as a subcontractor for several USG contractors and my products
wouldn't be possible without you, cheers! :)

After reading all these posts I wanted to throw in a response/question
regarding gdal/ogr and integration with VTK. Frank may remember last fall I
sent him a personal email informing him I had written a gdal/ogr/proj
wrapper for the AVS/Express visualization system. Since then AVS has tanked
and my customers have all started migrating to the VTK Visualization Toolkit
for their visualization apps.

VTK from www.kitware.com or public.kitware.com provides a tool for cross
platform projects named Cmake (currently 1.4 beta) that it seems would be
ideal for the gdal/ogr/proj/grass/... projects.

You basically provide a list of *.c, *.cpp, *.cxx files, headers, libraries
and hit the OK button. Cmake then builds your project files for you. It
works great on my winders and linux boxes, has anyone else tried it?

Why not use it??, it is released under the MIT license, same as GDAL/OGR
right?

Enlightment is always appreciated.

tp

-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at p...]
Sent: Thursday, June 06, 2002 11:26 PM
To: gdal-dev at yahoogroups.com
Subject: Re: [gdal-dev] packaging gdal for debian
-------------------------------------~->

paulbaker78 wrote:
> The problem is that gdal upstream does not build a shared library. I
> don't really have much experience with building libraries, so I'm not
> really sure quite what to do in order to make this happen. The
> combination of GNUMakefile and GDALMake.opt.in is not quite what I'm
> used to seeing. In GNUMakefile there is commented out near the top
> about using the commented out command instead of the one above in
> order to build a "proper SO files that will work in /usr/lib". This is
> of course what I need, but using that command instead of the upstream
> one doesn't seem to quite pull it off. The suggested command gives
> '-soname,gdal.so.1'. It really should be '-soname,libgdal.so.1' if I'm
> not mistaking. And besides the actual file that is created is
> libgdal.1.1.so which doesn't match either gdal.so.1 or libgdal.so.1.
>
> Before each distribution starts packaging up gdal in different ways
> with different sonames which will then completely break binary
> compatibility with programs trying to work with the shared library
> version from one distribution to another, upstream needs to hurry up
> and spell out just how it's going to be.
>
> Frank, if you are reading this, how open are you to working on getting
> real shared library build targets included in the upstream source? I
> hope you are willing before it is too late.

Paul,

I'm not sure why you say that GDAL doesn't build a shared library. I
assume you mean it doesn't produce a shared library with the usual
naming conventions. Is that right?

After soon initial hesitancy, I am now willing to revise how I build the
shared library to conform when conventions. I won't use libtool for reasons
I have tried to explain before, but I am willing to modify the configure
scripts to build with conventional names, and using -soname and so forth
set things right.

Hopefully we can roll this out as a GDAL 1.1.8 release in the relatively
near future.

Before I go digging for more details tomorrow, can anyone point me to what
I should be using as a link command on Linux?

Also, on the issue of having the separate development package. I am also
willing to separate out an install-slib, install-dev, install-bin and
install-all targets which would do:

install-slib: Just installs libgdal.so.1.x and support shared data.

install-bin: Installs various programs, and requires install-slib.

install-lib: Installs static library and include files.

install-all: Does all of the above.

I am also willing to review how GDAL installs figure out where to put
python.
Currently I used a bunch of custom configure logic to find where python
modules
belong, and try to install there. Often somewhere like
/usr/lib/python2.0/site-packages.
This gets put in the INST_PYMOD macro in GDALmake.opt, which can be
overridden
on the make commandline if need be. But there have been complaints that I
don't
honour --prefix settings for the python install. The problem is that the
python
modules can't work if they aren't installed where python is, unless people
extend
their PYTHONPATH or something. So what exactly do people want, and how will
it
produce a useful install tree?

PS. I run debian, but generally hesitate to install .debs for stuff like
PROJ.4
and GDAL for fear of confusing my local working configuration. I already
have
problems from having an installed copy of stuff in /usr/local and my local
builds
at times. I suppose I ought to setup an alternate bootable root on my
system for
testing stuff like this.

PPS. I would love to see a centralized package of gis/rs related debs
accumulated
somewhere like remotesensing.org. I can provide system access if this is
felt to
be a good idea. Does it make sense to do the same thing for rpms or should
we
leave this to the freegis guys who are already producing rpms for the
freegis CDs
anyways? Is there a redhat/rpm equilvelent to apt-get and co?

PPPS. I think we should have a mailing list or something for discussions of
packaging
of gis/rs related packages for debian. To avoid duplication, and to ensure
that the
various related technologies (GRASS, MapServer, PROJ.4, GDAL, OpenEV) can
work together
properly.

Best regards,

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