Tom Lane wrote:
>> if we fix some or all of the headers, what's the
>> plan for making sure that they stay fixed? Without a C++ buildfarm
>> member I think the chances of future breakage approach certainty.
>
> Actually, after re-reading the whole earlier thread I see that we did
> think of a possible answer to that:
> http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php
> which in fact is on the TODO list now. So if someone wanted to step
> up and make that happen, it would become sane to try to have C++-clean
> headers.
I'd be happy to work on that.
However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.
This would build one file - main.c - as C++ (necessary
because on some platforms the main() function needs to be
C++ to ensure the C++ runtime library is initialized).
The C++ compilation of main.c will fail if any C++
reserved words have been used as identifiers in the headers
included there. main.c already pulls in most of the headers
which are of interest for calling back in to postgres
(see attached .svg file). To complete the set, I could add
#include's for funcapi.h and spi.h.
C++-clean headers should be far less burdensome than trying
to keep the whole codebase C++-clean, because it is not very
often that someone would inadvertently choose a C++ reserved
word to use as a new field name or identifier in one of these
.h files; and main.c is not often changed.
(One of my patches - c++exception - adds a second file to
be C++ compiled (postgres.c). I'm planning to revise that
patch so that only main.c gets C++ compiled, to reduce the
exposure to inadvertent breakage of the --enable-cplusplus
build.)
Would it be worthwhile to make all the headers C++-clean,
rather than just the ones which seem likely to be pulled
in by a new access method, data type, or programming
language? The pgcompinclude proposal would be attractive
if every header file needs to be checked. (My opinion:
do that only if somebody needs it.)
Regards,
... kurt
