Added to TODO:

* Add automated check for invalid C++ source code constructs


Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> 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

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

Sent via pgsql-patches mailing list (
To make changes to your subscription:

Reply via email to