Status of sql_help.h
От | Tom Lane |
---|---|
Тема | Status of sql_help.h |
Дата | |
Msg-id | 1874.942531667@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] Status of sql_help.h
Re: [HACKERS] Status of sql_help.h |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: