Skip to content

Runner path types: decide between std::path and camino for the Ninja invocation chain #525

Description

@leynos

Observation

The Ninja request API (NinjaBuildRequest, NinjaToolRequest),
configure_ninja_base, and path_with_dir_prepended take
&std::path::Path, where the repository generally prefers camino's
Utf8Path. Raised in review of #497.

Why it was not changed there

Three reasons, in increasing order of weight.

It would be inconsistent if done partially. run_ninja and
run_ninja_tool already take &Path on main; the _with variants added by
#497 mirror them deliberately. Migrating only the new API leaves one module
with two conventions.

It is out of scope for that PR. #497 removes process-environment mutation
from the runner. Path types are orthogonal, and folding a signature migration
into it would bury the change reviewers need to see.

Done fully, it is a behavioural decision rather than a refactor. The values
flow in from Cli.file and Cli.directory, both PathBuf from clap, and from
resolve_ninja_program, which converts down from Utf8PathBuf to PathBuf
at line 78 — the codebase already widens deliberately at this boundary.
Utf8Path cannot represent a non-UTF-8 path, so migrating the whole chain
makes a build file or working directory with a non-UTF-8 name unrepresentable
rather than merely awkward. That may well be the right call, but it needs
deciding, not assuming.

Suggested work

  1. Decide whether non-UTF-8 build-file and working-directory paths are
    supported. If they are not, say so explicitly and fail early with a clear
    diagnostic rather than at an arbitrary later point.
  2. If they are unsupported, migrate the whole chain together —
    Cli.file, Cli.directory, resolve_ninja_program, the request types,
    configure_ninja_base, and path_with_dir_prepended — so one convention
    holds across the runner.
  3. Keep OsStr/OsString for environment-variable payloads, which genuinely
    need not be UTF-8.

Related: #497.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestmediumRoadmap items to schedule within the current quarter. Clear scope, normal review cycles.refactorBehaviour-preserving restructuring that improves code health.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions