> 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
