Add parse-bridges CLI subcommand

[integer-overflown]

What's this?

A new parse-bridges subcommand.
Also, an update to the documentation in the example showing this feature's preview.

This is handy for usage in higher-level build systems.
For example, in my case, I build both Rust and Swift with CMake, and having this CLI command implemented would allow generating the glue code from CMake as well, as a dependency step before building Rust/Swift targets (via add_custom_target API).

Notes

One caveat of the current implementation is that one would have to duplicate the crate name in the invocation line (the first argument).

This is fine for cases like mine, where this would be taken from the build system anyway, but it may not be handy for other cases.

The package name can be automatically deduced if one's running in the correct directory (the package root).
In this case, we can parse the cargo read-manifest output and get the name from there.

This would require a new dependency, though (serde_json), so I decided not to do this just yet, but if this sounds okay to you, I'll go ahead and implement this as well.

Examples

Single file:

swift-bridge-cli parse-bridges --crate-name my-awesome-crate -f src/lib.rs -o generated

Multiple files:

swift-bridge-cli parse-bridges --crate-name my-superb-crate \
-f src/lib.rs \
-f src/some_other_file.rs \
-o generated

[chinedufn]

Thanks for putting this together. Left some minor feedback.

---

One caveat of the current implementation is that one would have to duplicate the crate name in the invocation line (the first argument).

I'm not understanding what you mean here.

but if this sounds okay to you

Currently no known use cases where people would be repeatedly typing out this command by hand.

So, let's hold off on simplifying it and prefer explicit/obvious behavior for now.

---

Please update your PR body with an example of how the command looks.

When writing release notes we go to the PRs to grab examples.

We'll also sometimes link someone to an old similar PR, so it's nice to be able to look at the PR and immediately see what it's accomplishing.

[chinedufn]

Let's remove the default and require an explicit output directory.

Then we can consider introducing a default in the future if we decide that needing to specify the directory yourself is too cumbersome.

Reasons:

1. One fewer thing to figure out during this review. Adding a default would be a non-breaking change.

2. Fewer defaults helps teach the user about how things work / what is configurable

3. It is likely that users will write this command once and then re-use it, so it's okay if it's a little longer

[integer-overflown]

Good point, done.

I've force-pushed the changes.

[chinedufn]

Let's use --file / -f for each source file:

Let's use --crate-name for the crate name:

Reasons:

• allow arguments to be specified in any order
• more clear which argument is which. Right now <package name> and <file name> are right next to each other without any flags, making it a little harder to understand what each argument does.

[integer-overflown]

Done; updated the docs as well

[chinedufn]

No need to mention that subfolders are created automatically.
This information isn't useful to the user.

[integer-overflown]

I found this helpful :)

But I might be in the minority here, so I removed this.

[integer-overflown]

Thanks for reviewing.

I'm not understanding what you mean here.

Inferring crate name from the manifest if a user is located in the package root.

Currently no known use cases where people would be repeatedly typing out this command by hand.

So, let's hold off on simplifying it and prefer explicit/obvious behavior for now.

I agree; this would be less error-prone and more explicit.
As you also mentioned, this command will likely be written once, and then integrated into a script or build-system rules.

Please update your PR body with an example of how the command looks.

Good point; done, see the examples section.

[integer-overflown]

I removed this, as this is going to be handled by the shell script and the CLI.

[integer-overflown]

Also, something I noticed when modifying the docs...

This is the first and the last time "swiftc_link_rust" appears in the file.

This may be a typo.

Based on the swiftc command below, I think it will produce a "my_swift.a" file (based on the module name), so this should be

Suggested change

	println!("cargo:rustc-link-lib=static=swiftc_link_rust");
	println!("cargo:rustc-link-lib=static=my_swift");

What do you think?