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.
