Re: PostGIS spatial extensions

I would take a hard look at R's extension packaging system
(www.r-project.org) Its the best in the business. It consolidates all
aspects of creating packages, including configuring, building, run-time
linking, documentation and testing. It also allows non-root users to
install packages in their own account.

Tim

Peter Eisentraut wrote:

>Paul Ramsey writes:
>
>>- One of the things we have run up against is that for most linux
>>distributions, the postgresql-devel package does not include postgres.h
>>in the header package. This is not necessary for client-side programs,
>>but it is for server-side extensions. So people cannot compile our
>>extension without jettisoning their RPM version of postgresql and moving
>>to the tarball.
>>
>
>The 7.1 RPMs should contain the server side headers somewhere. Earlier
>versions only included a not very well defined subset of them.
>
>>- Where should extensions be installed by default? The RPM package has
>>some rules, the tarball has some other rules. Should extensions spread
>>themselves out over the postgresql tree (libs under lib, docs under doc,
>>etc) or should they be self-contained (postgis/lib postgis/doc) under
>>some other location?
>>
>
>This is a matter taste, or of the file system standard of the system you
>use. If you use autoconf and thus the GNU layout for your source package
>then the default is going to end up something like
>
>/usr/local/lib/postgis/postgis.so
>/usr/local/share/postgis/install-postgis.sql
>
>For binary distributions you'd fiddly with the configure --xxxdir flags a
>little.
>
>Maybe you had in mind some sort of standard layout under a standard
>directory, such as /usr/lib/postgresql/site-stuff (cf. perl), but this
>sort of a arrangement is a major pain. For instance, it won't allow
>non-root installs.
>

--
Timothy H. Keitt
Department of Ecology and Evolution
State University of New York at Stony Brook
Stony Brook, New York 11794 USA
Phone: 631-632-1101, FAX: 631-632-7626
http://life.bio.sunysb.edu/ee/keitt/