Become a sponsor to László Nagy

Sponsor Bear ʕ·ᴥ·ʔ

Bear generates the compile_commands.json file that clangd, clang-tidy and
other Clang tools need. You prefix your build command with bear -- and get the
database without changing the build system.

It is used where CMake or Meson are not an option: Make and autotools builds,
third-party code you cannot modify, embedded and HPC toolchains,
cross-compilers, ccache and distcc, and CI jobs where only a build log is
available. Bear is packaged by most Linux distributions, the BSDs, Homebrew and
MSYS2.

What sponsorship pays for

Mostly maintenance.

• Issue triage. Most reports are interactions between Bear and a toolchain I
  have not seen before. Reproducing them is where the time goes.
• Platform maintenance. Linux, macOS, FreeBSD, OpenBSD, NetBSD, DragonFly
  BSD and Windows, with two interception mechanisms. The CI matrix needs
  attention whenever a compiler, libc or OS release changes behaviour.
• Packaging support. Distribution maintainers need dependency versions that
  match what they ship and a predictable release process. The 4.1.x dependency
  floors were chosen so packagers need no substitution patches.
• Correctness work. Compiler flag handling, response files, MSVC and
  clang-cl argument parsing, non-UTF-8 arguments, precompiled headers.

Current state

Bear 4.x is a rewrite in Rust. It dropped the C++ dependencies (gRPC, protobuf,
spdlog, nlohmann-json, fmt), replaced gRPC with plain TCP, merged the former
intercept and citnames stages into one driver, and processes events during
interception rather than after the build. It added Windows support and a YAML
configuration file.

Both interception mechanisms work: library preload where the platform allows it,
compiler wrappers where it does not. Wrappers are how Bear works under macOS SIP
and on Windows. Builds that cannot be run at all are handled by parsing dry-run
output or a saved build log.

Recent releases added relative and canonical path output, configurable duplicate
detection when merging results, and directory-level include/exclude rules.

Planned work

• Interception coverage. The remaining gap is builds whose tools are
  statically linked and which ignore CC/CXX, so neither preload nor wrappers
  apply. ptrace is the candidate on Linux and the BSDs. eBPF would be better
  but needs privileges Bear cannot assume.
• Process supervision. Capturing exit codes and timing, not only process
  creation. A compile that failed should not look like one that succeeded.
• Cross-project merging. Combining results from separate projects into one
  database, so static analysis can run across module boundaries. Partly possible
  now. The open problem is file identity when the projects depend on each other.
• Documentation. The wiki holds most of the platform-specific knowledge and
  needs reorganising.

Not planned

• Build profiling. Execution timing makes it possible, but -ftime-trace,
  ClangBuildAnalyzer and .ninja_log already cover this. I will expose the data
  and leave it at that.
• Automated build system migration. A record of what a build actually did is
  in principle enough to help port a project to another build system. I find the
  idea interesting. I am not working on it.
• Feature requests as a sponsor benefit. Sponsorship does not buy a position
  in the queue. I read every issue either way.

Practicalities

I maintain Bear in my own time, alongside a full-time job, from Sydney. It gets
about four hours a week. Sponsorship does not add hours to that. It makes
spending them here easier to justify, and covers the running costs.

If your company depends on Bear in its build or CI, a recurring sponsorship is
more useful than a one-off. Contact me directly if you need an invoice.

Bear is GPL-3.0 and stays free either way. Sponsorship is not required to use
it, report a bug, or ask a question.