Re: development setup and libdir

Поиск
Список
Период
Сортировка
От Ivan Sergio Borgonovo
Тема Re: development setup and libdir
Дата
Msg-id 20100130233636.360ab8eb@dawn.webthatworks.it
обсуждение исходный текст
Ответ на Re: development setup and libdir  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: development setup and libdir  (Greg Smith <greg@2ndquadrant.com>)
Re: development setup and libdir  (Robert Haas <robertmhaas@gmail.com>)
Re: development setup and libdir  (James William Pye <lists@jwp.name>)
Re: development setup and libdir  (Euler Taveira de Oliveira <euler@timbira.com>)
Re: development setup and libdir  (Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk>)
Список pgsql-hackers
On Sat, 30 Jan 2010 16:51:44 -0500
Andrew Dunstan <andrew@dunslane.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: development setup and libdir
Следующее
От: Tim Bunce
Дата:
Сообщение: Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]