Thread: Status of sql_help.h
I see that src/bin/psql/sql_help.h is now generated automatically
from the SGML documentation. This is a Good Thing. But: since
sql_help.h is now a derived file, shouldn't it be removed from the
CVS repository, for the same reasons that we don't keep gram.c
and other derived files in CVS? If we leave it there, it'll generate
a lot of extra update traffic.
The only reason I can see for leaving it in CVS is that if we remove it,
people who pull sources from CVS would need Perl in order to build psql.
(People who download tarballs would *not*, since release_prep updates
sql_help.h along with the other derived files.) That's annoying, but
I think it may not be a fatal objection. Most hackers are probably
more likely to already have Perl than to already have bison or flex...
I thought about suggesting that create_help.pl be rewritten in some
"more portable" fashion such as an awk script. But really, if you
consider non-Unix platforms, Perl is more portable than awk or any
other likely alternative. (It might be worthwhile to remove the one
or two unnecessary Perl-5-isms in the script, so that it will run on
Perl 4 if that's what's available.)
Comments? Anyone feel that we really can't expect users of the CVS
repository to have Perl?
regards, tom lane
PS: "make distclean" should probably not remove sql_help.h, for the
same reasons that we don't remove gram.c --- it *is* a distributed
file, and a particular user might not have the tools to rebuild it.
This is true whether or not we leave it in CVS.
On 1999-11-13, Tom Lane mentioned: > sql_help.h is now a derived file, shouldn't it be removed from the > CVS repository, for the same reasons that we don't keep gram.c You're the CVS guys. Whatever works. > I thought about suggesting that create_help.pl be rewritten in some > "more portable" fashion such as an awk script. But really, if you If I'm supposed to maintain this (or do *anything* with it), it can't be awk. No reason to make a step backwards to accomodate an undocumented portability problem. I would argue that a lot more people are familiar with Perl and can read that script than an awk alternative. We don't write strict (-pedantic) ANSI C code either for the sake of portability. > other likely alternative. (It might be worthwhile to remove the one > or two unnecessary Perl-5-isms in the script, so that it will run on > Perl 4 if that's what's available.) On a quick look I couldn't find a useful listing of things new in Perl 5 or some way to test for Perl 4 compatibility. Shortly, I don't know what a Perl-5-ism is and I really don't feel like finding out either. However, if someone is inclined to fix those things if it doesn't make it all ugly, be my guest. > Comments? Anyone feel that we really can't expect users of the CVS > repository to have Perl? If you don't have Perl, the question is really: Do you have CVS? Do you have rlogin? Do you have networking support in your kernel? Do you have a computer? Seriously, I'd suggest that we wait for a documented problem before taking unnecessary steps. Hmm, interesting. From the GNU Makefile standards: "The `configure' script and the Makefile rules for building and installation should not use any utilities directly except these: cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true" No awk there either. > PS: "make distclean" should probably not remove sql_help.h, for the > same reasons that we don't remove gram.c --- it *is* a distributed > file, and a particular user might not have the tools to rebuild it. That was my bad. For some reason I had the idea that "distclean" stood for "distinctly clean" (really clean). :-\ I'll fix that. Perhaps we ought to decide on some standard targets. "maintainer-clean" would be the proper one to use (in GNU, again). It also contains the note: "... Since these files are normally included in the distribution, we don't take care to make them easy to reconstruct. If you find you need to unpack the full distribution again, don't blame us." Well said. -Peter -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> "The `configure' script and the Makefile rules for building and
> installation should not use any utilities directly except these:
> cat cmp cp diff echo egrep expr false grep install-info
> ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true"
> No awk there either.
Do I need to point out that Perl isn't there either? But this GNU rule
is irrelevant, because it applies to tools needed to build a standard
*distribution* of a package. Maintainer tools can include other things.
Using perl to generate sql_help.h seems perfectly appropriate to me,
as I said before.
What I wanted to find out was whether there were a lot of people using
the CVS server who don't have Perl and would object to installing it.
That's what will determine whether we can remove sql_help.h from the CVS
archive (as opposed to distributed tarballs).
>> PS: "make distclean" should probably not remove sql_help.h, for the
>> same reasons that we don't remove gram.c --- it *is* a distributed
>> file, and a particular user might not have the tools to rebuild it.
> That was my bad. For some reason I had the idea that "distclean" stood for
> "distinctly clean" (really clean). :-\ I'll fix that. Perhaps we ought to
> decide on some standard targets. "maintainer-clean" would be the proper
> one to use (in GNU, again).
No, it wouldn't be. We use distclean precisely as specified in the GNU
coding standards:
`distclean' Delete all files from the current directory that are created by configuring or building the program.
Ifyou have unpacked the source and built the program without creating any other files, `make distclean' should
leaveonly the files that were in the distribution.
sql_help.h will now be in the distribution, therefore distclean
shouldn't remove it.
regards, tom lane
> I see that src/bin/psql/sql_help.h is now generated automatically > from the SGML documentation. This is a Good Thing. But: since > sql_help.h is now a derived file, shouldn't it be removed from the > CVS repository, for the same reasons that we don't keep gram.c > and other derived files in CVS? If we leave it there, it'll generate > a lot of extra update traffic. > > The only reason I can see for leaving it in CVS is that if we remove it, > people who pull sources from CVS would need Perl in order to build psql. > (People who download tarballs would *not*, since release_prep updates > sql_help.h along with the other derived files.) That's annoying, but > I think it may not be a fatal objection. Most hackers are probably > more likely to already have Perl than to already have bison or flex... > > I thought about suggesting that create_help.pl be rewritten in some > "more portable" fashion such as an awk script. But really, if you > consider non-Unix platforms, Perl is more portable than awk or any > other likely alternative. (It might be worthwhile to remove the one > or two unnecessary Perl-5-isms in the script, so that it will run on > Perl 4 if that's what's available.) > > Comments? Anyone feel that we really can't expect users of the CVS > repository to have Perl? Because we have proper dependency, any change to sgml will force the next committer to commit a new sql_help.h right? If so, seems like it will work fine as is. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026