Skip site navigation (1) Skip section navigation (2)

Re: pgxs: build infrastructure for extensions v4

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: pgxs: build infrastructure for extensions v4
Date: 2004-07-29 05:22:59
Message-ID: Pine.GSO.4.58.0407290708380.25885@chailly99 (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Dear peter,

> > Please find attached another new version of a patch which provides a
> > working infrastructure for pg extensions. I hope it addresses all of
> > Peter's comments. I'll be away for the next 3 weeks, so if minor
> > changes are required it would be best if you could proceed without
> > me...
> This patch breaks building outside the source tree in a very elaborate
> and obvious way.  Unfortunately, this is all tied together so I haven't
> figured out yet if it can be fixed easily.

I do not get your point. the aim is to be able to build outside the source
tree as well?

> Also, the use of the install targets is a bit strange
> (install-all-headers install libpgport.a).  I would simply not bother
> and install everything all the time.  However, those who advocate the
> install-all-headers target may want to propose a different scheme.

part of this existed before the patch. I tried to make the best of
existing targets, especially as you requested that less targets should be
used. I do agree with you that installing libgport.a under
install-all-headers looks stupid, but the idea behind all-headers is that
all which is required for extensions is installed.

What about install-dev-files? or anything less misleading?

> > I updated all contrib makefiles so that they can be used either the
> > standard way after a configure, or the new way without needing a
> > configure but with an already installed postgreSQL. Just try them
> > with
> >
> > 	"cd contrib/foo ; make USE_PGXS=1 install"
> >
> > *AFTER* postgresql has been configure, compiled and installed.  It
> > should be compiled and installed wrt to the first "pg_config" which
> > is found in the path.
> This is redundant.  I think by now I'm looking for a patch that does not
> touch contrib at all (except perhaps

I really just touch that file in contrib. The only other exceptions are
when other files were directly included or to reorder include wrt mqcro
definitions, as far as I can remember.

> Much of the trouble arises from being too clever around there.  We're
> trying to allow external modules to build, not internal ones.

I really want to be able to install contribs as an afterthought and
without reconfiguring.

anyway, sorry I cannot really help as I m away from home.
Have a nice day,

Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr

In response to

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2004-07-29 05:49:54
Subject: Re: Quick coding question with acl fixes
Previous:From: Fabien COELHODate: 2004-07-29 05:04:39
Subject: Re: try/catch macros for Postgres backend

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-07-29 05:52:13
Subject: Re: pg_ctl -o option dumps core when processing postmaster arguments...
Previous:From: Alvaro HerreraDate: 2004-07-28 23:53:33
Subject: Re: [subxacts] Fixing TODO items

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group