building without perl
I'm a bit confused as to what we're trying to support. While I was
poking around tonight, I notice that we have both
./src/backend/utils/Gen_fmgrtab.sh and
./src/backend/utils/Gen_fmgrtab.pl, ostensibly because:
# The reason for implementing this functionality twice is that we don't
# require people to have perl to build from a tarball, but on the other
# hand Windows can't deal with shell scripts.
However, you definitely can't build from a git (or, presumably, CVS)
checkout without perl, and in fact the error message leaves a good
deal to be desired. Configure succeeds, but then:
[...lots of output omitted...]
make -C ../../../../src/port all
make[5]: Entering directory `/home/rhaas/pgsql-git/src/port'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/home/rhaas/pgsql-git/src/port'
"" ./parse.pl . < ../../../../src/backend/parser/gram.y > preproc.y
/bin/sh: : command not found
make[4]: *** [preproc.y] Error 127
make[4]: *** Deleting file `preproc.y'
make[4]: Leaving directory `/home/rhaas/pgsql-git/src/interfaces/ecpg/preproc'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/rhaas/pgsql-git/src/interfaces/ecpg'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/rhaas/pgsql-git/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/rhaas/pgsql-git/src'
make: *** [all] Error 2
I've seen previous references to perl being a build requirement as
well, so I guess I'm a bit confused. Is there some tarball that is
built with just enough extra stuff in it to avoid the perl dependency?
And if so, how confident are we that we're solving a real problem
here as opposed to a hypothetical one? Admittedly, I tend to use
machines running relatively recent operating system versions, but I
think the last time that I ran into a machine that didn't have perl on
it was not more recently than 1994 (I'm guessing someone is now going
to tell me what a sheltered life I lead...).
...Robert
Robert Haas <robertmhaas@gmail.com> writes:
I'm a bit confused as to what we're trying to support.
You are not supposed to need perl to build from a release tarball
(except on Windows which doesn't have a decent make or shell, so we
depend on perl instead). You do need it to build from a CVS checkout.
Same story as bison/flex.
make -C ../../../../src/port all
make[5]: Entering directory `/home/rhaas/pgsql-git/src/port'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/home/rhaas/pgsql-git/src/port'
"" ./parse.pl . < ../../../../src/backend/parser/gram.y > preproc.y
/bin/sh: : command not found
make[4]: *** [preproc.y] Error 127
make[4]: *** Deleting file `preproc.y'
Hmm, that's a new dependency on perl, and it wasn't properly guarded
... will fix.
I think the last time that I ran into a machine that didn't have perl on
it was not more recently than 1994 (I'm guessing someone is now going
to tell me what a sheltered life I lead...).
Yup.
regards, tom lane
On Mon, Jun 22, 2009 at 10:12 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I'm a bit confused as to what we're trying to support.
You are not supposed to need perl to build from a release tarball
(except on Windows which doesn't have a decent make or shell, so we
depend on perl instead). You do need it to build from a CVS checkout.
Same story as bison/flex.
FWIW, README.CVS mentions bison and flex but not perl.
So, is our policy that it's OK to use perl to generate things, as long
as they are things that are architecture-independent and
configuration-independent therefore could be pregenerated for the
release tarball? If so, it seems we might be able to punt
Gen_fmgrtab.sh and just keep Gen_fmgrtab.pl...
make -C ../../../../src/port all
make[5]: Entering directory `/home/rhaas/pgsql-git/src/port'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/home/rhaas/pgsql-git/src/port'
"" ./parse.pl . < ../../../../src/backend/parser/gram.y > preproc.y
/bin/sh: : command not found
make[4]: *** [preproc.y] Error 127
make[4]: *** Deleting file `preproc.y'Hmm, that's a new dependency on perl, and it wasn't properly guarded
... will fix.I think the last time that I ran into a machine that didn't have perl on
it was not more recently than 1994 (I'm guessing someone is now going
to tell me what a sheltered life I lead...).Yup.
I suppose this was intended to be funny, but I'd be curious as to the details.
...Robert
Robert Haas <robertmhaas@gmail.com> writes:
So, is our policy that it's OK to use perl to generate things, as long
as they are things that are architecture-independent and
configuration-independent therefore could be pregenerated for the
release tarball? If so, it seems we might be able to punt
Gen_fmgrtab.sh and just keep Gen_fmgrtab.pl...
Yeah, that was discussed when Gen_fmgrtab.pl was written, but we kept
the old method around out of sheer conservatism (not to mention that the
early versions of Gen_fmgrtab.pl weren't very good).
I think the last time that I ran into a machine that didn't have perl on
it was not more recently than 1994 (I'm guessing someone is now going
to tell me what a sheltered life I lead...).Yup.
I suppose this was intended to be funny, but I'd be curious as to the details.
Actually, further investigation discloses that someone broke the no-Perl
defense in psql's makefile back in 8.0, and we hadn't noticed till now.
So it certainly seems to be the case that nobody associated with the
Postgres project works in a Perl-free environment. Nonetheless, the
makefiles are supposed to behave sanely if Perl is missing.
regards, tom lane
Tom Lane wrote:
Actually, further investigation discloses that someone broke the no-Perl
defense in psql's makefile back in 8.0, and we hadn't noticed till now.
So it certainly seems to be the case that nobody associated with the
Postgres project works in a Perl-free environment. Nonetheless, the
makefiles are supposed to behave sanely if Perl is missing.
Don't we ship sql_help.h in the tarball? I thought that's all the perl
was used for in psql.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Actually, further investigation discloses that someone broke the no-Perl
defense in psql's makefile back in 8.0, and we hadn't noticed till now.
Don't we ship sql_help.h in the tarball? I thought that's all the perl
was used for in psql.
Yeah, but the makefile protected that with "ifdef PERL", which stopped
failing as intended when someone forced some quotes into the value of
PERL. I'm about to commit something that hopefully will be a bit more
robust.
regards, tom lane
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Actually, further investigation discloses that someone broke the no-Perl
defense in psql's makefile back in 8.0, and we hadn't noticed till now.Don't we ship sql_help.h in the tarball? I thought that's all the perl
was used for in psql.Yeah, but the makefile protected that with "ifdef PERL", which stopped
failing as intended when someone forced some quotes into the value of
PERL. I'm about to commit something that hopefully will be a bit more
robust.
Oh. Oops!
cheers
andrew
On Tuesday 23 June 2009 06:43:29 Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Actually, further investigation discloses that someone broke the no-Perl
defense in psql's makefile back in 8.0, and we hadn't noticed till now.Don't we ship sql_help.h in the tarball? I thought that's all the perl
was used for in psql.Yeah, but the makefile protected that with "ifdef PERL", which stopped
failing as intended when someone forced some quotes into the value of
PERL. I'm about to commit something that hopefully will be a bit more
robust.
So one would have only seen the difference if there was a timestamp skew in
the unpacked tarball, or indeed perl was indeed missing.
Peter Eisentraut <peter_e@gmx.net> writes:
Yeah, but the makefile protected that with "ifdef PERL", which stopped
failing as intended when someone forced some quotes into the value of
PERL. I'm about to commit something that hopefully will be a bit more
robust.
So one would have only seen the difference if there was a timestamp skew in
the unpacked tarball, or indeed perl was indeed missing.
Well, the case we're really trying to deal with (as in, fail cleanly on)
is a build from CVS without perl.
regards, tom lane