Re: PostGIS spatial extensions

From: "Timothy H(dot) Keitt" <tklistaddr(at)keittlab(dot)bio(dot)sunysb(dot)edu>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Paul Ramsey <pramsey(at)refractions(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS spatial extensions
Date: 2001-08-15 21:07:07
Message-ID: 3B7AE47B.1010902@keittlab.bio.sunysb.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-08-15 21:23:22 Re: Re: To be 7.1.3 or not to be 7.1.3?
Previous Message Jan Wieck 2001-08-15 21:05:22 Re: Dollar in identifiers

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2001-08-15 21:08:12 Re: Re: Proposal for encrypting pg_shadow passwords
Previous Message Bruce Momjian 2001-08-15 20:59:37 Re: Fix for fetchone() and fetchmany() in Python interface