| Age | Commit message (Collapse) | Author |
|---|
|
Teach it to scrape -I and -D switches from CPPFLAGS in Makefile.global.
This is useful for testing on, eg, FreeBSD, where you won't get far
without "-I/usr/local/include".
Also, expand the set of blacklisted-for-unportability atomics headers,
based on noting that arch-x86.h fails to compile on an ARM box. The
other ones I'd omitted seem to compile all right on architectures they
don't belong to, but that's surely too shaky to rely on. Let's do
like we did for the src/include/port/ headers, and ignore all except
the variant that's pulled in by the arch-independent header.
|
|
Declaring a function "inline" still doesn't work with Windows compilers
(C99? what's that?), unless the macro provided by pg_config.h is
in-scope, which it is not in our ECPG test programs. So the workaround
I tried to use in commit 7640f9312 doesn't work for Windows. Revert
the change in printf_hack.h, and instead just blacklist that file
in cpluspluscheck --- since it's a not-installed test file, we don't
really need to verify its C++ cleanliness anyway.
|
|
Formerly, cpluspluscheck was only meant to examine headers that
we thought of as exported --- but its notion of what we export
was well behind the times. Let's just make it check *all* .h
files, except for a well-defined blacklist, instead.
While at it, improve its ability to use a C++ compiler other than g++,
by scraping the CXX setting from Makefile.global and making it possible
to override the warning options used (per suggestion from Andres Freund).
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
|
|
Previously cpluspluscheck wouldn't work in vpath builds, this commit
fixes that. To make it easier to invoke, there's a top-level
cpluspluscheck target.
Discussion: https://postgr.es/20190530220244.kiputcbl4gkl2oo6@alap3.anarazel.de
|
|
Some things in src/include/fe_utils require libpq headers, so add
libpq's include path to the command line used here.
|
|
They can include sys/sdt.h from SystemTap, which itself contains C++
code and so won't compile with a C++ compiler under extern "C" linkage.
|
|
It is not meant to be included standalone.
|
|
Error exposed by recent Assert changes.
Complaint from Peter Eisentraut.
|
|
|
|
No longer needed now that bitand() and bitor() have been renamed.
|
|
This is slower than the original coding but avoids the problem of
including files in an unpredictable order. Aside from being more
trustworthy, we can get rid of some exclusions that were formerly
made for what turn out to be ordering or re-inclusion problems.
I also modified it to include libpq's exported files in the check.
ecpg should be included as well, but I'm unclear on which ecpg .h
files are meant to be included by clients.
|
|
gram.h has ordering dependencies, which are satisfied when it's included
from gramparse.h, but might not be if it's pulled in directly.
|
|
This alters various incidental uses of C++ key words to use other similar
identifiers, so that a C++ compiler won't choke outright. You still
(probably) need extern "C" { }; around the inclusion of backend headers.
based on a patch by Kurt Harriman <harriman@acm.org>
Also add a script cpluspluscheck to check for C++ compatibility in the
future. As of right now, this passes without error for me.
|
