From: | Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: development setup and libdir |
Date: | 2010-01-30 22:36:36 |
Message-ID: | 20100130233636.360ab8eb@dawn.webthatworks.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 30 Jan 2010 16:51:44 -0500
Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Ivan Sergio Borgonovo wrote:
> > It is becoming a more serious issue than what I thought...
> > Debian install everything in
> > /usr/lib/postgresql/8.3/lib/
> > -rw-r--r-- 1 root root
> > so definitively it would be hard to write there.
> >
> > Still I'd like to keep a standard installation of Debian and just
> > compile my extension somewhere else where the postgres user can
> > read.
[snip]
> > What am I supposed to do to install modules where I want?
> pgxs is about building somrthing that will install in the
> configured locations. If you don't want to install in the
> configured locations don't build/install with pgxs.
> For development purposes you would be far better off building a
> private version of postgres (with configure --prefix=/path) and
> using its pgxs to build, install and test your module.
That's pretty expensive.
I mean... I just would like my .so end up with the expected name
somewhere else.
I can put up a working postgres installation just using aptitude and
having a semi-functional[1] dev environment installing postgres -dev
package. Requiring I compile a private version of postgres[1]
increase the cost of development unreasonably, considering that
what's missing is being able to provide install dir as a parameter
during make install
I'm absolutely aware I can't ask features unless someone is willing
to implement them or is paid for... but the easier/cheaper it is to
build up a dev/test environment the more people will try to
build/test something for postgres.
Of course I can write a script that can workaround this.
It seems that the only thing missing is that pgxs 8.3 used to
prefix .so with lib and then rename them at install time, but pgxs
8.4 build them directly without prefix.
I'm just speculating this is the issue and it is the only one I
still have to solve... but... what's going to happen next release?
Wouldn't it be better if make install could install stuff where I
ask so I could put modules in different places *even* for the same
installation of postgres?
I'll write my script. I can do my homework and I'm not expecting
someone else make using pgxs nicer but still it doesn't look an
unreasonable feature.
I mean... what's so weird about being able to develop postgres
modules without requiring people build the whole postgresql or
switching back and forward from root?
And... it's really a pity... I mean... I'm so near to build and test
modules just doing
aptitude install postgresql postgresql-server-dev-8.4
[1] that's not just compile, you've to set it up, make it start at
boot, make it work on a different port... There is already a lot of
work made by distribution packagers. Why should it be wasted?
[2] semi-functional... because I can't actually install modules with
the provided tools where I'd like to have them.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Bunce | 2010-01-30 23:16:08 | Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH] |
Previous Message | Andrew Dunstan | 2010-01-30 21:51:44 | Re: development setup and libdir |