|
| 1 | +% External tools |
| 2 | + |
| 3 | +One of the goals of Cargo is simple integration with third-party tools, like |
| 4 | +IDEs and other build systems. To make integration easier, Cargo has several |
| 5 | +facilities: |
| 6 | + |
| 7 | +* `cargo metadata` command, which outputs project structure and dependencies |
| 8 | + information in JSON, |
| 9 | + |
| 10 | +* `--message-format` flag, which outputs information about a particular build, |
| 11 | + |
| 12 | +* support for custom subcommands. |
| 13 | + |
| 14 | + |
| 15 | +# Information about project structure |
| 16 | + |
| 17 | + |
| 18 | +You can use `cargo metadata` command to get information about project structure |
| 19 | +and dependencies. The output of the command looks like this: |
| 20 | + |
| 21 | +```text |
| 22 | +{ |
| 23 | + // Integer version number of the format. |
| 24 | + "version": integer, |
| 25 | +
|
| 26 | + // List of packages for this workspace, including dependencies. |
| 27 | + "packages": [ |
| 28 | + { |
| 29 | + // Opaque package identifier. |
| 30 | + "id": PackageId, |
| 31 | +
|
| 32 | + "name": string, |
| 33 | +
|
| 34 | + "version": string, |
| 35 | +
|
| 36 | + "source": SourceId, |
| 37 | +
|
| 38 | + // A list of declared dependencies, see `resolve` field for actual dependencies. |
| 39 | + "dependencies": [ Dependency ], |
| 40 | +
|
| 41 | + "targets: [ Target ], |
| 42 | +
|
| 43 | + // Path to Cargo.toml |
| 44 | + "manifest_path": string, |
| 45 | + } |
| 46 | + ], |
| 47 | +
|
| 48 | + "workspace_members": [ PackageId ], |
| 49 | +
|
| 50 | + // Dependencies graph. |
| 51 | + "resolve": { |
| 52 | + "nodes": [ |
| 53 | + { |
| 54 | + "id": PackageId, |
| 55 | + "dependencies": [ PackageId ] |
| 56 | + } |
| 57 | + ] |
| 58 | + } |
| 59 | +} |
| 60 | +``` |
| 61 | + |
| 62 | +The format is stable and versioned. When calling `cargo metadata`, you should |
| 63 | +pass `--format-version` flag explicitly to avoid forward incompatibility |
| 64 | +hazard. |
| 65 | + |
| 66 | +If you are using Rust, there is [cargo_metadata] crate. |
| 67 | + |
| 68 | +[cargo_metadata]: https://crates.io/crates/cargo_metadata |
| 69 | + |
| 70 | + |
| 71 | +# Information about build |
| 72 | + |
| 73 | +When passing `--message=format=json`, Cargo will output the following |
| 74 | +information during the build: |
| 75 | + |
| 76 | +* compiler errors and warnings, |
| 77 | + |
| 78 | +* produced artifacts, |
| 79 | + |
| 80 | +* results of the build scripts (for example, native dependencies). |
| 81 | + |
| 82 | +The output goes to stdout in the JSON object per line format. The `reason` field |
| 83 | +distinguishes different kinds of messages. |
| 84 | + |
| 85 | +Information about dependencies in the Makefile-compatible format is stored in |
| 86 | +the `.d` files alongside the artifacts. |
| 87 | + |
| 88 | + |
| 89 | +# Custom subcommands. |
| 90 | + |
| 91 | +Cargo is designed to be extensible with new subcommands without having to modify |
| 92 | +Cargo itself. This is achieved by translating a cargo invocation of the form |
| 93 | +cargo `(?<command>[^ ]+)` into an invocation of an external tool |
| 94 | +`cargo-${command}` that then needs to be present in one of the user's `$PATH` |
| 95 | +directories. |
| 96 | + |
| 97 | +Custom subcommand may use `CARGO` environment variable to call back to |
| 98 | +Cargo. Alternatively, it can link to `cargo` crate as a library, but this |
| 99 | +approach has drawbacks: |
| 100 | + |
| 101 | +* Cargo as a library is unstable, API changes without deprecation, |
| 102 | + |
| 103 | +* versions of Cargo library and Cargo binary may be different. |
0 commit comments