Laszlo Nagy
fc7eb4ad91
`cc` and `c++` are GCC on most Linuxes but Clang on FreeBSD, OpenBSD, NetBSD, DragonFly, and macOS. The regex defaulted them to GCC, which corrupted the compilation database on those hosts via wrong flag-arity tables (e.g. Clang's `-Xclang <arg>` consumes the next argv slot, GCC's does not). Recognition now runs `--version` lazily for these ambiguous basenames, classifies by signature, and dispatches accordingly. The probe is the sole classifier: gcc.yaml deliberately omits `cc`/`c++`, so a failed probe returns NotRecognized rather than guessing -- a missing entry is visible and debuggable, whereas a wrongly-classified entry corrupts the database silently via mismatched flag-arity tables (the bug this work exists to fix). Layered design: - CompilerRecognizer dispatches. - CompilerProbe classifies. VersionProbe on Unix (hardened: closed stdin, process-group SIGKILL on timeout, LD_PRELOAD / DYLD_INSERT_LIBRARIES stripped); NoProbe on Windows where basenames are unambiguous and the Unix subprocess primitives the probe relies on aren't available. - CachingProbe memoizes the probe's verdict per canonical path so each unique compiler is fork-exec'd at most once per process. A user `compilers:` entry preempts the probe -- the sole supported override. Also simplifies the WrapperInterpreter that the probe work exposed: replaces the cyclic Arc::new_cyclic + OnceLock<Box<dyn Interpreter>> + Weak<dyn Interpreter> machinery with a flat wrapper::unwrap() helper called inline from CompilerInterpreter::recognize. See requirements/recognition-ambiguous-name-probe.md for the spec. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ʕ·ᴥ·ʔ Build EAR
Bear generates a compilation database for Clang tooling.
The JSON compilation database describes how each translation unit is compiled. Clang-based tools use it to understand compiler flags, include paths, and other build settings.
Some build systems can generate a JSON compilation database directly. For build systems that cannot, Bear captures compiler invocations during the build and writes the database for you.
How to install
Bear is packaged for many distributions. Check your distribution's package manager first. Alternatively, you can build it from source.
How to use
After installation, run:
bear -- <your-build-command>
Bear writes compile_commands.json to the current working directory.
For more options, see the man page or run bear --help. Pass Bear’s own
options before --; everything after that is treated as part of the build command.
Please be aware that some package managers still ship the 2.4.x release. In
that case, please omit the extra -- or consult your local documentation.
For more information, read the man pages or the project wiki, which talks about limitations, known issues, and platform-specific usage.
When to use Bear
Use Bear when your build system does not natively support generating a JSON compilation database. If your project already uses CMake, Meson, or Bazel, prefer the built-in compilation database export those tools provide; it is usually faster and more reliable.
Supported platforms
Bear works on Linux, macOS, FreeBSD, OpenBSD, NetBSD, DragonFly BSD, and Windows.
Limitations
Bear works by intercepting compiler calls during a build. This means certain environments may need extra configuration — for example, macOS System Integrity Protection (SIP) or sandboxed builds (Nix, Flatpak). See the wiki for details and workarounds.
Problem reports
Before opening a new problem report, please check the wiki to see if your problem is a known issue with a documented workaround. It's also helpful to look at older (possibly closed) issues before opening a new one.
If you decide to report a problem, please provide as much context as possible to help reproduce the error. If you just have a question about usage, please don't be shy; ask your question in an issue or in our chat.
If you've found a bug and have a fix for it, please share it by opening a pull request.
Please follow the contribution guide when you do.