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
Attachments:
patch.difftext/plain; charset=UTF-8; name=patch.diff; x-mac-creator=0; x-mac-type=0Download
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'
On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby <Jim.Nasby@bluetreble.com> 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
Robert Haas wrote:
On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby <Jim.Nasby@bluetreble.com> 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 Herrera http://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
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby <Jim.Nasby@bluetreble.com> 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
On Nov 2, 2015, at 1:07 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
Attachments:
smime.p7sapplication/pkcs7-signature; name=smime.p7sDownload
0� *�H��
��0�1 0 + 0� *�H��
�� i0�-0��Q�0
*�H��
0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0
150909050437Z
160909073817Z0F1 0 U david@justatheory.com1$0" *�H��
david@justatheory.com0�"0
*�H��
� 0�
� �zg� ��P����������:�BV��h/�a�UcTD��L������V�9
��&��2��O*@@�g� ���E�����!�Ta��G��� ��R�B�����RI �\ g��K��. 7���� ����8��,dr��B��}���F��)�y��n��3 8�]$D) ��g �'
Hz�"�������`EVl�{ <���q�h��A �-���=��:�m���nlxsN~� ����jo���s�FV������1IB8p�1 ���0��0 U 0 0 U �0 U %0++0 U ���D�!���<�rV6
���0 U #0�Sr������\|~�5N���Q�0 U 0�david@justatheory.com0�LU �C0�?0�; +��70�*0.+"http://www.startssl.com/policy.pdf0��+0��0' StartCom Certification Authority0��This certificate was issued according to the Class 1 Validation requirements of the StartCom CA policy, reliance only for the intended purpose in compliance of the relying party obligations.06U /0-0+�)�'�%http://crl.startssl.com/crtu1-crl.crl0��+��009+0�-http://ocsp.startssl.com/sub/class1/client/ca0B+0�6http://aia.startssl.com/certs/sub.class1.client.ca.crt0#U 0�http://www.startssl.com/0
*�H��
� r��������.��;�-a��������� ��L ��O� � 4���}��F�,^��Y�,�'�d���7:�LR|��s=�9v|\K �� C�@�Y����VW� h Ev����M6� �I�oIJ!y����l_�������� ��3������V [�\�n sD����|�~u����P ��Tn� C��_V!�{A�>��;g���^��,�a�d�X�T��vlO7��L��S>���N*i]m���R�tn����/k0�40� � 0
*�H��
0}1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0
071024210155Z
171024210155Z0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0�"0
*�H��
� 0�
� � ���-��)�.����2����A�UG��o���#G�
��B|N�D�����Rp�M-��B��=o��� -�we�5��J�Qpa>O��.�#������.���_�<���V��
[~�*��*�p�z��~�3�W�G� .�������Ml�r[�<C�e�6���f����q������O���"��u��xf�WN�#�u����i���c�gk��v$����Lb�%�������y��`�����_�{`���xK'G�N��� ���0��0U �0�0U �0 U Sr������\|~�5N���Q�0 U #0�N ��@[�i�0�4hC�A��0f+Z0X0'+0�http://ocsp.startssl.com/ca0-+0�!http://www.startssl.com/sfsca.crt0[U T0R0'�%�#�!http://www.startssl.com/sfsca.crl0'�%�#�!http://crl.startssl.com/sfsca.crl0��U y0w0u +��70f0.+"http://www.startssl.com/policy.pdf04+(http://www.startssl.com/intermediate.pdf0
*�H��
�
�}x�,\�c�^� �#wM�q�}��>UK/��^y��X��y �����f�rMI���B6�1ymQ���������Z���0���& ��;�@��#13q����& ����������o� 6�r��_��;�GO>*I�( 7�4����XS1r3��)!����y��6Ko����t��#
_�w�S�r����
�;�B
A�Dp�(f��s����� �����6%�����.W0J3�:b�C�<�8t X����1�<��C��n�=�����t==�wS���T������~���\�wkB�f�|1���5���zU��P)��(���I��j��VB��!����OfI=b��b�\4�-*em��/��SJm�7���N�����[�]'��@���� D9�Kr>���R��7/����|�o���^I@���'��Pa $ z��9�a'L�)��(�
�I��}v��c�H]����D����*��W�}
m�>Q����|�C.�(,�l��Q�1�o0�k0��0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CAQ�0 + ���0 *�H��
1 *�H��
0 *�H��
1
151102224645Z0# *�H��
1YX�A& b����S[Kx�R0�� +�71��0��0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CAQ�0�� *�H��
1�����0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CAQ�0
*�H��
� �A u,� �.��-�A�G����2��Jl0���
���qWUP���\��_��&) ������}H��>c�E��
�?�b��BC>��bkB���aK9������5�lv������D_����}� Eh��^Pq�i�0m�mj����6�JG�{K�o���7h�K#��9�/C^��P���������s��m1�%����p�����j��)�!�1� B`�
F�������a�I.�C����e`�J�G��){��l
Bg[;�Q8 
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.
Attachments:
missing.patchapplication/x-patch; name=missing.patchDownload
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'$@' $<
Peter Eisentraut <peter_e@gmx.net> 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
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
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 Herrera http://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
On 11/11/2015 12:34 PM, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> 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
Andrew Dunstan <andrew@dunslane.net> 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
Alvaro Herrera <alvherre@2ndquadrant.com> 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
/messages/by-id/5633BA23.3030201@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
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 Herrera http://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