Getting started with the Kythe codebase

Instructions to build Kythe from source

Code review

All changes to Kythe must go through code review before being submitted, and each individual or corporate contributor must sign an appropriate Contributor License Agreement. Once your CLA is submitted (or if you already submitted one for another Google project), make a commit adding yourself to the AUTHORS and CONTRIBUTORS files. This commit can be part of your first Pull Request.

The Kythe team has chosen to use GitHub Pull Requests for code review.

Linting and Testing

Run ./tools/git/setup_hooks.sh to initialize the standard Git hooks used by the Kythe developers. This ensures that each commit passes all unit/lint tests and that commit descriptions follow the Conventional Commits specification before a requesting code review. If necessary, use git commit --no-verify to bypass these checks. In addition to the tools necessary to build Kythe, the following are necessary to run the installed hooks:

  • pre-commit
  • buildifier
  • clang-format (>= 11)
  • gofmt
  • golint
  • google-java-format
  • jq
  • shellcheck

Each Pull Request will also require a gambit of tests run Google Cloud Build. All non-maintainers will require a Kythe team member to add a /gcbrun comment in each Pull Request to verify the PR should be checked by presubmits.

Style formatting

Kythe C++ code follows the Google style guide. You can run clang-format to do this automatically:

clang-format -i --style=file <filename>

If you forgot to do this for a commit, you can amend it easily:

clang-format -i --style=file $(git show --pretty="" --name-only <SHA1>)
git commit --amend

Likewise, all Java code should be formatted by the latest version of google-java-format and Go code should pass through gofmt.

Contribution Ideas

Along with working off of our tasks list (and, in particular, the Wishlist), there are many ways to contribute to Kythe.

New Extractors and Indexers

Kythe is built on the idea of having a common set of tools across programming languages so Kythe is always happy to add another language to its family.

Build System Integration

In order to use Kythe’s compilation extractors, they must be given precise information about how a compilation is processed. Currently, Kythe has built-in support for Bazel and rudimentary support for CMake. Contributing support for more build systems like Gradle will greatly help the ease of use for Kythe and increase the breadth of what it can index.

User Interfaces

Kythe emits a lot of data and there are many ways to interpret/display it all. Ideas for visualizers include an interactive graph, a documentation browser and a source file hierarchical overview.