Hi Andrew,
On Mon, Sep 23, 2013 at 6:43 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm working on it. It appears to have a slight problem or two I want to fix
at the same time, rather than backpatch something broken.
Any progress on this? I notice that the fixes didn't make it into 9.3.1.
On 09/23/2013 12:15 PM, Cédric Villemain wrote:
I'm working on it. It appears to have a slight problem or two I want
to fix at the same time, rather than backpatch something broken.
Would you mind sharing the problems you are facing ?
You've noticed the problem about installdirs, I suppose.
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp ma...@juffo.org wrote:
On Fri, Sep 13, 2013 at 6:42 PM, Cédric Villemain ced...@2ndquadrant.com
wrote:
Andrew is about to commit (well...I hope) a doc patch about that and also a
little fix.
Imho this is a bugfix so I hope it will be applyed
Marti Raudsepp wrote:
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp ma...@juffo.org wrote:
Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6
Improve support for building PGXS modules with VPATH fixes the
problem and I see it's not present in REL9_3_0.
Andrew and
On 09/23/2013 11:31 AM, Alvaro Herrera wrote:
Marti Raudsepp wrote:
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp ma...@juffo.org wrote:
Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6
Improve support for building PGXS modules with VPATH fixes the
problem and I see it's not
Le lundi 23 septembre 2013 11:43:13 Andrew Dunstan a écrit :
On 09/23/2013 11:31 AM, Alvaro Herrera wrote:
Marti Raudsepp wrote:
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp ma...@juffo.org
wrote:
Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6
Improve support for
On Tue, Sep 17, 2013 at 10:37 AM, Cédric Villemain
ced...@2ndquadrant.com wrote:
Erm, isn't apt.postgresql.org supposed to ship the *official*
PostgreSQL versions? Given that this issue affects all distros, I
don't see why Ubuntu/Debian need to be patched separately.
Well, the patches are
Apt.pgdg got the patch present in postgresql head applyed.
Erm, isn't apt.postgresql.org supposed to ship the *official*
PostgreSQL versions? Given that this issue affects all distros, I
don't see why Ubuntu/Debian need to be patched separately.
Well, the patches are applyed on the debian
Marti Raudsepp ma...@juffo.org a écrit :
On Tue, May 14, 2013 at 4:12 AM, Marti Raudsepp ma...@juffo.org
wrote:
While testing out PostgreSQL 9.3beta1, I stumbled upon a problem
% make DESTDIR=/tmp/foo install
/usr/bin/install: will not overwrite just-created
On Fri, Sep 13, 2013 at 6:42 PM, Cédric Villemain
ced...@2ndquadrant.com wrote:
Marti Raudsepp ma...@juffo.org a écrit :
Did we ever do anything about this? It looks like the thread got
distracted with VPATH builds and now I'm seeing this problem in 9.3.0.
Andrew is about to commit (well...I
On Tue, May 14, 2013 at 4:12 AM, Marti Raudsepp ma...@juffo.org wrote:
While testing out PostgreSQL 9.3beta1, I stumbled upon a problem
% make DESTDIR=/tmp/foo install
/usr/bin/install: will not overwrite just-created
‘/tmp/foo/usr/share/postgresql/extension/semver--0.3.0.sql’ with
Le mardi 28 mai 2013 14:10:14, Cédric Villemain a écrit :
I just took time to inspect our contribs, USE_PGXS is not supported by
all of them atm because of SHLIB_PREREQS (it used submake) I have a
patch pending here to fix that.
Attached patch fix SHLIB_PREREQS when building with USE_PGXS
Le mardi 28 mai 2013 15:15:55, Cédric Villemain a écrit :
Le samedi 25 mai 2013 16:41:24, Cédric Villemain a écrit :
If it seems to be on the right way, I'll keep fixing EXTENSION
building with VPATH.
I haven't tried the patch, but let me just say that Debian (and
On 05/29/2013 06:08 PM, Cédric Villemain wrote:
I just took time to inspect our contribs, USE_PGXS is not supported by all
of them atm because of SHLIB_PREREQS (it used submake) I have a patch
pending here to fix that. Once all our contribs can build with USE_PGXS I
fix the VPATH.
I've
Le jeudi 30 mai 2013 14:32:46, Stefan Kaltenbrunner a écrit :
On 05/29/2013 06:08 PM, Cédric Villemain wrote:
I just took time to inspect our contribs, USE_PGXS is not supported by
all of them atm because of SHLIB_PREREQS (it used submake) I have a
patch pending here to fix that. Once all
I just took time to inspect our contribs, USE_PGXS is not supported by all
of them atm because of SHLIB_PREREQS (it used submake) I have a patch
pending here to fix that. Once all our contribs can build with USE_PGXS I
fix the VPATH.
I've added 'most' of the patches to the commitfest... (I am
I just took time to inspect our contribs, USE_PGXS is not supported by all
of them atm because of SHLIB_PREREQS (it used submake) I have a patch
pending here to fix that.
Attached patch fix SHLIB_PREREQS when building with USE_PGXS
commit 19e231b introduced SHLIB_PREREQS but failed to port
Once all our contribs can build with USE_PGXS I
fix the VPATH.
The last step is interesting: installcheck/REGRESS. For this one, if I can
know exactly what's required (for debian build for example), then I can
also fix this target.
There is a hack to link the regression data files from the
Once all our contribs can build with USE_PGXS I
fix the VPATH.
Attached patch set VPATH for out-of-tree extension builds
If the makefile is not in the current directory (where we launch 'make')
then assume we are building out-of-src tree and set the VPATH to the
directory of the *first*
Le mardi 28 mai 2013 14:16:38, Cédric Villemain a écrit :
Once all our contribs can build with USE_PGXS I
fix the VPATH.
The last step is interesting: installcheck/REGRESS. For this one, if I
can know exactly what's required (for debian build for example), then I
can also fix this
Le samedi 25 mai 2013 16:41:24, Cédric Villemain a écrit :
If it seems to be on the right way, I'll keep fixing EXTENSION building
with VPATH.
I haven't tried the patch, but let me just say that Debian (and
apt.postgresql.org) would very much like the VPATH situation getting
If it seems to be on the right way, I'll keep fixing EXTENSION building
with VPATH.
I haven't tried the patch, but let me just say that Debian (and
apt.postgresql.org) would very much like the VPATH situation getting
improved. At the moment we seem to have to invent a new build recipe
Re: Cédric Villemain 2013-05-25 201305251641.28401.ced...@2ndquadrant.com
I just took time to inspect our contribs, USE_PGXS is not supported by all of
them atm because of SHLIB_PREREQS (it used submake) I have a patch pending
here to fix that. Once all our contribs can build with USE_PGXS I
Re: Cédric Villemain 2013-05-17 201305171642.59241.ced...@2ndquadrant.com
If it seems to be on the right way, I'll keep fixing EXTENSION building with
VPATH.
I haven't tried the patch, but let me just say that Debian (and
apt.postgresql.org) would very much like the VPATH situation getting
Le jeudi 16 mai 2013 18:53:19, Alvaro Herrera a écrit :
Andrew Dunstan wrote:
On 05/16/2013 10:39 AM, Cédric Villemain wrote:
Le jeudi 16 mai 2013 15:51:48, Tom Lane a écrit :
Andrew Dunstan and...@dunslane.net writes:
On 05/16/2013 05:41 AM, Dimitri Fontaine wrote:
And VPATH building
Andrew Dunstan and...@dunslane.net writes:
DATA_built = sql/$(EXTENSION)--$(EXTVERSION).sql
DATA = $(filter-out sql/$(EXTENSION)--$(EXTVERSION).sql, $(wildcard
sql/*--*.sql))
Is that right?
I think that's still breaking VPATH builds because the widlcard call
happens in the current tree, not
On 05/16/2013 05:41 AM, Dimitri Fontaine wrote:
Andrew Dunstan and...@dunslane.net writes:
DATA_built = sql/$(EXTENSION)--$(EXTVERSION).sql
DATA = $(filter-out sql/$(EXTENSION)--$(EXTVERSION).sql, $(wildcard
sql/*--*.sql))
Is that right?
I think that's still breaking VPATH builds because the
Andrew Dunstan and...@dunslane.net writes:
On 05/16/2013 05:41 AM, Dimitri Fontaine wrote:
And VPATH building of extension is crucially important for me, as the
easiest way I've found to build and package a given extension against
all currently supported version of PostgreSQL.
Is there
Le jeudi 16 mai 2013 15:51:48, Tom Lane a écrit :
Andrew Dunstan and...@dunslane.net writes:
On 05/16/2013 05:41 AM, Dimitri Fontaine wrote:
And VPATH building of extension is crucially important for me, as the
easiest way I've found to build and package a given extension against
all
On 05/16/2013 10:39 AM, Cédric Villemain wrote:
Le jeudi 16 mai 2013 15:51:48, Tom Lane a écrit :
Andrew Dunstan and...@dunslane.net writes:
On 05/16/2013 05:41 AM, Dimitri Fontaine wrote:
And VPATH building of extension is crucially important for me, as the
easiest way I've found to build
Andrew Dunstan wrote:
On 05/16/2013 10:39 AM, Cédric Villemain wrote:
Le jeudi 16 mai 2013 15:51:48, Tom Lane a écrit :
Andrew Dunstan and...@dunslane.net writes:
On 05/16/2013 05:41 AM, Dimitri Fontaine wrote:
And VPATH building of extension is crucially important for me, as the
easiest
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Then there's the outright weird stuff using ancient makefiles ..
*grumble* pg_filedump *grumble*
I've never made any effort to improve the original makefile for that.
Want to send a patch?
regards, tom lane
--
Sent via
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Then there's the outright weird stuff using ancient makefiles ..
*grumble* pg_filedump *grumble*
I've never made any effort to improve the original makefile for that.
Want to send a patch?
Not right away, but I will get to
On Tue, May 14, 2013 at 10:30 PM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I still think we should revert 9db7ccae2000524b72a4052352cbb5407fb53b02.
The argument that the system-provided program might be faster carries
very little weight for me --- make
On 5/14/13 5:45 PM, Tom Lane wrote:
We changed to using install-sh unconditionally back in 2001 because
we had too many problems with system-provided scripts that didn't do
what we expected. I see very little reason to believe that the
compatibility problems have disappeared since then, and
On 5/14/13 10:38 AM, Cédric Villemain wrote:
If I follow your example, then I would rewrite http://manager.pgxn.org/howto
Oh that's where that is coming from? Well that example has all kinds of
problems.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Peter Eisentraut pete...@gmx.net writes:
That said, I'm obviously outnumbered here. What about the following
compromise: Use the configure-selected install program inside
PostgreSQL (which we can test easily), and use install-sh under
USE_PGXS? Admittedly, the make install time of
Le mardi 14 mai 2013 15:08:42, Andrew Dunstan a écrit :
On 05/14/2013 07:59 AM, Peter Eisentraut wrote:
On 5/14/13 4:17 AM, Marti Raudsepp wrote:
On Tue, May 14, 2013 at 5:27 AM, Peter Eisentraut pete...@gmx.net
wrote:
On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
It's caused
On 05/15/2013 10:05 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
That said, I'm obviously outnumbered here. What about the following
compromise: Use the configure-selected install program inside
PostgreSQL (which we can test easily), and use install-sh under
USE_PGXS?
On Wed, May 15, 2013 at 09:51:15AM -0400, Peter Eisentraut wrote:
On 5/14/13 10:38 AM, Cédric Villemain wrote:
If I follow your example, then I would rewrite http://manager.pgxn.org/howto
Oh that's where that is coming from? Well that example has all kinds of
problems.
Would you be so
Le mercredi 15 mai 2013 16:43:17, Andrew Dunstan a écrit :
On 05/15/2013 10:05 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
That said, I'm obviously outnumbered here. What about the following
compromise: Use the configure-selected install program inside
PostgreSQL (which
On Tue, May 14, 2013 at 5:27 AM, Peter Eisentraut pete...@gmx.net wrote:
On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
It's caused by this common pattern in extension makefiles:
DATA = $(wildcard sql/*--*.sql) sql/$(EXTENSION)--$(EXTVERSION).sql
What is the point of this? Why have
Le mardi 14 mai 2013 10:17:13, Marti Raudsepp a écrit :
On Tue, May 14, 2013 at 5:27 AM, Peter Eisentraut pete...@gmx.net wrote:
On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
It's caused by this common pattern in extension makefiles:
DATA = $(wildcard sql/*--*.sql)
Marti Raudsepp ma...@juffo.org writes:
all: sql/$(EXTENSION)--$(EXTVERSION).sql
sql/$(EXTENSION)--$(EXTVERSION).sql: sql/$(EXTENSION).sql
cp $ $@
That's a recipe for problems. Each time I meet with such a construct in
an extension's Makefile I propose an hard coded alternative. We're
On 5/13/13 10:58 PM, Andrew Dunstan wrote:
I'm not sure why the wildcard is a bad idea - don't we want any present
update sql files to be installed?
Generally, wildcards in makefiles are a bad idea because you will then
not discover any broken tarballs and checkouts. The users will just
On 5/14/13 4:17 AM, Marti Raudsepp wrote:
On Tue, May 14, 2013 at 5:27 AM, Peter Eisentraut pete...@gmx.net wrote:
On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
It's caused by this common pattern in extension makefiles:
DATA = $(wildcard sql/*--*.sql)
On 5/14/13 7:50 AM, Dimitri Fontaine wrote:
Marti Raudsepp ma...@juffo.org writes:
all: sql/$(EXTENSION)--$(EXTVERSION).sql
sql/$(EXTENSION)--$(EXTVERSION).sql: sql/$(EXTENSION).sql
cp $ $@
That's a recipe for problems. Each time I meet with such a construct in
an extension's
On 05/14/2013 07:59 AM, Peter Eisentraut wrote:
On 5/14/13 4:17 AM, Marti Raudsepp wrote:
On Tue, May 14, 2013 at 5:27 AM, Peter Eisentraut pete...@gmx.net wrote:
On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
It's caused by this common pattern in extension makefiles:
DATA =
Le mardi 14 mai 2013 10:17:13, Marti Raudsepp a écrit :
On Tue, May 14, 2013 at 5:27 AM, Peter Eisentraut pete...@gmx.net wrote:
On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
It's caused by this common pattern in extension makefiles:
DATA = $(wildcard sql/*--*.sql)
On Tue, May 14, 2013 at 2:59 PM, Peter Eisentraut pete...@gmx.net wrote:
Perhaps, but fixing the extensions is not a solution at this point. A
large number of extensions use this exact code (it comes from David
Wheeler's template AFAIK).
So far, the number is still less than the number of
Marti Raudsepp ma...@juffo.org writes:
I did a quick and dirty survey of extensions on PGXN and found that
the install change causes problems for (at least) 22% of extensions
there. I think it's well worth the time to implement a workaround,
rather than hassle extension writers.
What's really
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I still think we should revert 9db7ccae2000524b72a4052352cbb5407fb53b02.
The argument that the system-provided program might be faster carries
very little weight for me --- make install is fast enough already.
It's not worth making a bunch of extension
Marti Raudsepp ma...@juffo.org writes:
While testing out PostgreSQL 9.3beta1, I stumbled upon a problem
installing some extensions (pgTAP and semver among others):
...
I traced the problem down to commit
9db7ccae2000524b72a4052352cbb5407fb53b02 Use system install program
when available and
On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
It's caused by this common pattern in extension makefiles:
DATA = $(wildcard sql/*--*.sql) sql/$(EXTENSION)--$(EXTVERSION).sql
What is the point of this? Why have the wildcard and then the
non-wildcard term?
I think using wildcard is
On 05/13/2013 10:27 PM, Peter Eisentraut wrote:
On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
It's caused by this common pattern in extension makefiles:
DATA = $(wildcard sql/*--*.sql) sql/$(EXTENSION)--$(EXTVERSION).sql
What is the point of this? Why have the wildcard and then
55 matches
Mail list logo
