Re: development setup and libdir

On Sat, 30 Jan 2010 22:25:32 -0200
Euler Taveira de Oliveira <euler(at)timbira(dot)com> wrote:

> Ivan Sergio Borgonovo escreveu:
> > That's pretty expensive.
> >
> Ugh?
>
> > I mean... I just would like my .so end up with the expected name
> > somewhere else.
> It's just two command lines [1].

Consider I'm absolutely new to postgres C development.

I'm pretty sure that what you're pointing at is not going to work
unless you specify a bunch of other parameters.
I've to count the time I've to spend to learn what is needed and and
whenever I'll stumble into a bug/unexpected behaviour I'll have to
take into account the time I'll spend wondering if I did miss to
pass any parameter that caused that behaviour.

Then I'm not aware of all the magic that pgxs and makefiles are
doing.

Once you ask... people direct you to pgxs. pgxs seems a good
choice... a newcomer like me thinks... well that was made exactly to
pick up all the information it needs from the environment and build
my module.

And it works and it is simple.

> > 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?
> Why do you want to mess your installation? Besides, you will need
> to add the install path in dynamic_library_path and or the
> absolute path to your CREATE FUNCTION script. Man, that's too much
> work for a packager! Of course, you can always build on your way;
> that's up to you.

> > 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?

> Ugh? You don't need root; I mean, you can always set absolute path
> or even the dynamic_library_path [2] parameter.

Absolute path requires that *the code* has to be different for every
installation.
dynamic_library_path looks more "interesting" if it spans just a
connection, but still different version of pgxs gives different
names to .so.

If the absolute path could be set as a parameter passed to make that
would be better.
Anyway pg 8.3 make install change the name of libraries, so passing
the absolute path depends on the version on which you're building.
So it's not enough to write a "post processing" script that sed the
install.sql.
As said I'm able to write a script that will check if libmodule.so
or module.so were generated and then "fix" the instal.sql[1], but
still that's a workaround that may break in future versions... maybe
postgres 9.0 will build libraries in a subdirectory of the source
and then install will rename and move them with a different pattern.

I think the most compelling reason for building postgres from source
for people that would like to "occasionally" develop modules is
having debug symbols.

Maybe my point of view really sound alien to many in the hacker list
since the learning curve to develop in C with postgres seems pretty
selective so people here already decided to invest pretty much of
their time into postgres... but many people may just would like to
try. There are several shades of gray between "screwing my system
postgres" and "test using a private installation".
That's exactly why I'd like to keep my modules out of the system dir
but still use the system postgres.
I'm developing my module to see if it can serve a need of another
project. What should I do then? make a private installation of
apache and php as well?
Develop my module on a private instance then deploy it in my test
env, with system postgres for the other project then move it to the
staging box...
Costs add up, and right now I'd just like to try if I can come up
with something useful.

[1] that's exactly what I'm going to do. When I'll have a working
module I'll see if that's enough for me or I want to do more complex
work and I need a more advanced development environment.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it