Re: SPI-header-files safe for C++-compiler
| От | Tom Lane |
|---|---|
| Тема | Re: SPI-header-files safe for C++-compiler |
| Дата | |
| Msg-id | 26405.1183565103@sss.pgh.pa.us обсуждение |
| Ответ на | Re: SPI-header-files safe for C++-compiler (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
| Ответы |
Re: SPI-header-files safe for C++-compiler
|
| Список | pgsql-patches |
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> wild idea - we could add a bit of configure magic and a special makefile
> target and add a buildfarm stage for that and have it automatically
> check for these things ?
I had been idly toying with the idea of making a tool to check for C++
problems, when it occurred to me that we already have almost the right
thing: src/tools/pginclude/pgcompinclude is a script that checks that
each .h file in the system can be compiled without any other preceding
inclusions except postgres.h. If run with a C++ compiler instead of C,
seems it would accomplish the task we want.
As it stands, pgcompinclude seems to lack a number of things but they're
all fixable:
* hard-wired compiler name and flags
* hard-wired paths
* should use postgres_fe.h not postgres.h for frontend-usable
include files (would need a clearer policy for which those are)
* possible use of unportable idioms (not sure, needs checked)
Given a cleaned-up version of pgcompinclude, we could add a buildfarm
option to invoke it using a specified compiler and options. I don't
think we need every buildfarm member doing that but getting a
representative sample doing so would be a Good Thing. Even without
considering the C++ angle, this is an area that's easy to break
and having quicker feedback would be good. The current practice of
manually running pgcompinclude once in awhile lacks a lot, notably
coverage of different sets of compile options (see notes at the bottom
of src/tools/pginclude/README).
Anybody feel like working on that?
regards, tom lane
В списке pgsql-patches по дате отправления: