Re: development setup and libdir

On Sun, 31 Jan 2010 02:44:13 -0200
Euler Taveira de Oliveira <euler(at)timbira(dot)com> wrote:

> Ivan Sergio Borgonovo escreveu:
> > I'm pretty sure that what you're pointing at is not going to work
> > unless you specify a bunch of other parameters.

> Ugh? Are you saying there is something wrong in our *official*
> documentation? It is just a normal compilation command; if you're
> a C programmer you'll have no problem.

Well I think if I didn't have to compile for 8.3 I'd be more
naturally guided to a solution since when make install does more
than just moving files, you wonder if it is doing even more.
I still don't know if make install is doing something more other
than moving/renaming files.

Still I think the documentation doesn't provide a reasonable path to
*try* to write "Hello world".
Actually there isn't even a "suggested" path that works unless you
knock at pgsql-hackers and ask for details.

Of course explanation on how to compile manually an extension
without pgxs and a template makefile aren't sufficient.

When I'd like to try something new I'd like to put myself in the
most diffused, standard environment eg. one thing I'd like to avoid
is choosing my own flavour of compile options.

So... what's better than providing a template makefile?
And there is one, and it works.

But postgres makefile read module.sql.in and output module.sql. I'd
consider module.sql.in part of the source of the project and I'd
think it has to be "relocatable" without change.

Now you use pgsx and it works great...
You've your .so there, you look at the pattern used in the .sql, you
adapt it and it still does work. Oh look! 8.3 change the .so name at
make install.
You adapt it once more but that makes you wonder... is make install
doing something else?
It would be better if:
a) you document what make install is really doing
or
b) provided that contrib make install just move stuff around you let
specify people where they would like to install the lib at make time
so a sensible module.sql is produced

b) looks easier to maintain and easier to use. But as said I may have
a naïve idea of what really means providing a working build system
for many architecture/OSes.

No rocket science indeed. I'm not crying, I've already written
mysimple script to just post-process module.sql. I'm describing my
experience so you may be aware of the problems that new comers face.
It is up to the people that will write actual code/docs to see if it
is worth for them to do so.

As soon as I'll feel comfortable to write something worth I'll write
some docs.

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

> Again, PGXS was developed to make packagers' life easier. Why on
> earth I want to install my library in a path different from
> $libdir? Packagers don't. Besides, PGXS won't work on Windows
> unless you're using a installation built using MinGW.

This is something like you bought a car to go from Paris to Berlin
but you can't use it to go to Marseilles just because you don't have
a map.
pgxs and debian packages did a nearly perfect job even for my needs.

Being able to compile and install an extension without a full dev
environment and without being root has a non empty set of reasonable
applications. Making easier to automate it out of the box doesn't
look a bad thing.

Sorry if it seemed I was complaining, I was trying to give feedback
while learning my way to write "Hello world".

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