Re: [HACKERS] Status of sql_help.h - Mailing list pgsql-hackers

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