-
We are using Clang-Tidy.
-
We use the current stable release in CI, which is version 11.
-
To get started, a very small set of checks are run continuously, with an eye to expanding the set gradually as we modernize and improve the code base.
-
Unlike formatting, developers can run newer versions of clang-tidy locally and fix more warnings.
We have a convenience script for running clang-tidy.
This script needs the path to a directory containing the compilation database (compile_commands.json
)
The script makes use of GNU Parallel and clang-tidy
.
To install them on macOS:
brew install parallel llvm
On Debian-derivative Linux distributions, you have more choices on the version of clang-tidy, e.g.:
apt-get install parallel clang-tidy-12
Alternatively apt-get install clang-tidy
will give you a "default" version of clang-tidy
from the distribution.
Here's an example of generating two build directories, build.debug
and build.release
at the root of Greenplum repository:
for debug build:
$ CXX=clang++ cmake -GNinja -Hsrc/backend/gporca -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Debug -Bbuild.debug
and release:
$ CXX=clang++ cmake -GNinja -Hsrc/backend/gporca -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -Bbuild.release
To check (it's unsurprising if we pass the check in one configuration but not another)
$ src/tools/tidy chk-orca build.debug
and
$ src/tools/tidy chk-orca build.release
Note that the script assumes the name of clang-tidy
is clang-tidy
and it can be found on your PATH
.
So if you're (typically) using clang-tidy
from Homebrew's LLVM package, you'll override that assumption by e.g.:
$ CLANG_TIDY=/usr/local/opt/llvm/bin/clang-tidy src/tools/tidy chk-orca build.debug
The main Greenplum codebase, like upstream PostgreSQL, uses autoconf and GNU Make as the build system. This means that we'll need another tool, like Bear. The following example assumes you start from the root of a check-out of our Git repository:
mkdir ../vpath.debug
(
cd ../vpath.debug
../gpdb/configure --config-cache -enable-depend --enable-orca --enable-cassert CC="ccache clang" CXX="ccache clang++" CFLAGS='-O0' CXXFLAGS='-O0'
bear --append make -s -C src/backend/gpopt
)
mkdir ../vpath.release
(
cd ../vpath.release
../gpdb/configure --config-cache -enable-depend --enable-orca --disable-cassert CC="ccache clang" CXX="ccache clang++" CFLAGS='-O0' CXXFLAGS='-O0'
bear --append make -s -C src/backend/gpopt
)
The steps above will create two VPATH build directories, one with assertions enabled, and another without assertions. Each directory has a compilation database (generated by bear
intercepting the build commands) that understands the flags necessary to build the translator (src/backend/gpopt
).
If you have a compilation database (compile_commands.json
) that records the commands used to build files in src/backend/gpopt
, point the tidy
script to that:
$ src/tools/tidy chk-gpopt ../vpath.debug
$ src/tools/tidy chk-gpopt ../vpath.release