CliEndpointSupport
Shared by the 21 src/analyzer/analyzers/{lang}/cli.cr analyzers, which all
build the same thing: a set of cli://<binary> endpoints, one per
(sub)command, so that flags and env vars discovered in different files merge
onto one command.
It is a mixin rather than an inherited method because the CLI analyzers have
no common base below Analyzer: 17 extend Analyzer directly, while the Go,
JavaScript, Python and Ruby ones extend their language engine. Pushing this
onto Analyzer itself would hand a cli://-specific constructor to all ~200
analyzers, so the mixin is included by exactly the 21 that want it.
The other helpers those files carry — cli_test_path?, <lang>_binary_name,
cli_evidence? — each read a per-class constant whose value differs by
language (Perl's test tree is /t/, Scala's is /it/, Groovy's is
spec.groovy; the binary-name stem lists disagree too). Several are
therefore textually identical while resolving to different regexes, so
folding them on name would be a silent behaviour change. They stay where
they are — but the fallback half of <lang>_binary_name, which is genuine
duplication, lives here as cli_directory_binary_name.
Constants
Directory names that describe a project's layout rather than name the program inside it.
Files that mark a project root. A CLI file's nearest enclosing manifest is the program it belongs to; two files under different manifests are two programs even when their inferred binary names collide.
Deliberately excludes CMakeLists.txt / meson.build: those are written
per subdirectory in a normal build tree, so they mark layout rather than
a project boundary and would split one program into many.
Manifests named after the project rather than by a fixed basename.
Separator inside the endpoint-map key. A NUL can appear in neither a path nor a URL, so the three parts of the key (configured base, project directory, URL) can never be confused for one another.