Re: [HACKERS] Patch to install config/missing
Tom Lane wrote: > Given our inability to come to a consensus on rejiggering the uses of > "missing", I think maybe we should just apply the original patch and > call it good. For the record: Tom applied this patch as commit dccf8e9e608824ce15. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
Alvaro Herrera writes: > Peter Eisentraut wrote: >> On 11/11/15 12:34 PM, Tom Lane wrote: >>> I was thinking more of removing the "missing" script and associated logic >>> entirely, rather than making PGXS a special case. >> Well, about a year ago people were arguing for the opposite change in >> the documentation build. It used to default all the build tool >> variables to programs that weren't there, and people got all confused >> about that, so we stuck "missing" in there across the board. > Ah, right :-( It's obviously difficult to arrange a compromise that > pleases everyone here. I think it's fair to keep "missing" for the doc > build and remove it from Perl/bison/flex, regardless of pgxs; extensions > cannot build doc files anyway. I took a closer look at the originally proposed patch at http://www.postgresql.org/message-id/5633ba23.3030...@bluetreble.com and realized that my worry about it was based on a misconception: I thought it'd get installed into someplace where it might interfere with other packages. But actually, it would get installed into the same place we put install-sh, namely $PREFIX/lib/postgresql/pgxs/config/ (omitting postgresql/ if PREFIX already contains something PG-specific). So the argument that it could break anybody else seems pretty thin. Given our inability to come to a consensus on rejiggering the uses of "missing", I think maybe we should just apply the original patch and call it good. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
Andrew Dunstan writes: > On 11/11/2015 12:34 PM, Tom Lane wrote: >> I was thinking more of removing the "missing" script and associated logic >> entirely, rather than making PGXS a special case. I think we should do >> our best to minimize differences between behaviors in core builds and >> PGXS builds, if only because we don't test the latter very much and >> might not notice problems there. > At least two buildfarm members (crake and sitella) build FDWs using > PGXS. Of course, they aren't likely to uncover problems with missing > perl/bison/flex - especially perl ;-) But I don't want people to get the > idea we don't test PGXS regularly, because we do. I know we have buildfarm coverage, but by its nature that's not going to exercise scenarios like missing tools. You only find out about problems of that ilk from manual testing in non-controlled environments. And I think we have much more of that going on for the core build than for any add-on. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
On 11/11/2015 12:34 PM, Tom Lane wrote: Peter Eisentraut writes: On 11/2/15 4:07 PM, Tom Lane wrote: I wonder how much we need that script at all though. If, say, configure doesn't find bison, what's so wrong with just defining BISON=bison and letting the usual shell "bison: command not found" error leak through? I agree. Something like the attached patch. I was thinking more of removing the "missing" script and associated logic entirely, rather than making PGXS a special case. I think we should do our best to minimize differences between behaviors in core builds and PGXS builds, if only because we don't test the latter very much and might not notice problems there. At least two buildfarm members (crake and sitella) build FDWs using PGXS. Of course, they aren't likely to uncover problems with missing perl/bison/flex - especially perl ;-) But I don't want people to get the idea we don't test PGXS regularly, because we do. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
Peter Eisentraut wrote: > On 11/11/15 12:34 PM, Tom Lane wrote: > > I was thinking more of removing the "missing" script and associated logic > > entirely, rather than making PGXS a special case. I think we should do > > our best to minimize differences between behaviors in core builds and > > PGXS builds, if only because we don't test the latter very much and > > might not notice problems there. > > Well, about a year ago people were arguing for the opposite change in > the documentation build. It used to default all the build tool > variables to programs that weren't there, and people got all confused > about that, so we stuck "missing" in there across the board. Ah, right :-( It's obviously difficult to arrange a compromise that pleases everyone here. I think it's fair to keep "missing" for the doc build and remove it from Perl/bison/flex, regardless of pgxs; extensions cannot build doc files anyway. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
On 11/11/15 12:34 PM, Tom Lane wrote: > I was thinking more of removing the "missing" script and associated logic > entirely, rather than making PGXS a special case. I think we should do > our best to minimize differences between behaviors in core builds and > PGXS builds, if only because we don't test the latter very much and > might not notice problems there. Well, about a year ago people were arguing for the opposite change in the documentation build. It used to default all the build tool variables to programs that weren't there, and people got all confused about that, so we stuck "missing" in there across the board. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
Peter Eisentraut writes: > On 11/2/15 4:07 PM, Tom Lane wrote: >> I wonder how much we need that script at all though. If, say, configure >> doesn't find bison, what's so wrong with just defining BISON=bison and >> letting the usual shell "bison: command not found" error leak through? > I agree. Something like the attached patch. I was thinking more of removing the "missing" script and associated logic entirely, rather than making PGXS a special case. I think we should do our best to minimize differences between behaviors in core builds and PGXS builds, if only because we don't test the latter very much and might not notice problems there. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
On 11/2/15 4:07 PM, Tom Lane wrote: > I wonder how much we need that script at all though. If, say, configure > doesn't find bison, what's so wrong with just defining BISON=bison and > letting the usual shell "bison: command not found" error leak through? I agree. Something like the attached patch. diff --git a/src/Makefile.global.in b/src/Makefile.global.in index 51f4797..5379c90 100644 --- a/src/Makefile.global.in +++ b/src/Makefile.global.in @@ -293,8 +293,12 @@ ifneq (@PERL@,) # quoted to protect pathname with spaces PERL = '@PERL@' else +ifdef PGXS +PERL = perl +else PERL = $(missing) perl endif +endif perl_archlibexp = @perl_archlibexp@ perl_privlibexp = @perl_privlibexp@ perl_embed_ldflags = @perl_embed_ldflags@ @@ -597,6 +601,15 @@ TAS = @TAS@ # # Global targets and rules +ifdef PGXS +ifeq (,$(BISON)) +BISON = bison +endif +ifeq (,$(FLEX)) +FLEX = flex +endif +endif + %.c: %.l ifdef FLEX $(FLEX) $(if $(FLEX_NO_BACKUP),-b) $(FLEXFLAGS) -o'$@' $< -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
On Nov 2, 2015, at 1:07 PM, Tom Lane wrote: > I wonder how much we need that script at all though. If, say, configure > doesn't find bison, what's so wrong with just defining BISON=bison and > letting the usual shell "bison: command not found" error leak through? +1 This would certainly make it easier for downstream use cases, as well. Was not relishing having to parse the PERL variable to find out if Perl was missing. David smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Patch to install config/missing
Robert Haas writes: > On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby wrote: >> Currently, config/missing isn't being installed. This can lead to confusing >> error messages, such as if Perl isn't found and something needs it [1]. >> Attached patch adds it to install and uninstall recipes. > I find it somewhat hard to believe this is the right thing to do. But > if this isn't right, then I don't know what is right, either. Installing our "missing" script seems like a seriously bad idea. For one thing, as the comments in it note, it's similar but not identical to such a script that exists in many GNU packages; we could easily create problems for other packages that rely on other variants of it. I wonder how much we need that script at all though. If, say, configure doesn't find bison, what's so wrong with just defining BISON=bison and letting the usual shell "bison: command not found" error leak through? I'm not seeing that we get a very large increment of user-friendliness from interposing the "missing" script. In at least one way it's a net negative: if you go and install bison after getting the error, you will have to re-run configure to recover, whereas playing dumb would frequently have left us with the right configuration output already. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
Robert Haas wrote: > On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby wrote: > > Currently, config/missing isn't being installed. This can lead to confusing > > error messages, such as if Perl isn't found and something needs it [1]. > > Attached patch adds it to install and uninstall recipes. > > I find it somewhat hard to believe this is the right thing to do. But > if this isn't right, then I don't know what is right, either. I think 'missing' is as part of the development package as install-sh is -- and we're installing that one, so why not 'missing'? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch to install config/missing
On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby wrote: > Currently, config/missing isn't being installed. This can lead to confusing > error messages, such as if Perl isn't found and something needs it [1]. > Attached patch adds it to install and uninstall recipes. I find it somewhat hard to believe this is the right thing to do. But if this isn't right, then I don't know what is right, either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Patch to install config/missing
Currently, config/missing isn't being installed. This can lead to confusing error messages, such as if Perl isn't found and something needs it [1]. Attached patch adds it to install and uninstall recipes. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com diff --git a/config/Makefile b/config/Makefile index da12838..67e7998 100644 --- a/config/Makefile +++ b/config/Makefile @@ -7,9 +7,11 @@ include $(top_builddir)/src/Makefile.global install: all installdirs $(INSTALL_SCRIPT) $(srcdir)/install-sh '$(DESTDIR)$(pgxsdir)/config/install-sh' + $(INSTALL_SCRIPT) $(srcdir)/missing '$(DESTDIR)$(pgxsdir)/config/missing' installdirs: $(MKDIR_P) '$(DESTDIR)$(pgxsdir)/config' uninstall: rm -f '$(DESTDIR)$(pgxsdir)/config/install-sh' + rm -f '$(DESTDIR)$(pgxsdir)/config/missing' -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
