Обсуждение: 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 solvinga 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