option to produce single-target binary crates

[spernsteiner]

Currently, when c2rust-transpile is run with --binary main_cu, it generates a Cargo crate with two targets, a lib target and a bin target. It puts the main compilation unit main_cu in the bin target and puts all other compilation units in the lib target. This means there are two separate targets, both of which contain non-trivial code.

It would be convenient for CRISP if there was only one target to worry about. One option would be to put all compilation units into the bin target, and remove the lib target entirely. Another option would be to put all compilation units into the lib target, and have the bin target consist only of a trivial stub that calls lib::main().

[Rua]

Letting the user specify this with the command line seems the most sensible? Just as cargo new lets you specify the crate type, c2rust transpile should as well. And of course this should control what kind of Cargo.toml it generates.

[ahomescu]

specify the crate type, c2rust transpile should as well

I don't think that's what we're talking about here, right? @spernsteiner is asking for binary+library to be folded into a single binary crate, right?

[spernsteiner]

Yes, either fold all the code into a single binary target, or fold it all into a library with a trivial main.rs. The goal is to have all of the interesting code end up in a single Rust compilation unit, which makes it easier to analyze and refactor.

[brk]

Incidentally this would have two other benefits:

1. c2rust's division of symbols between bin and lib can produce cross-target cyclic dependencies. When symbols are unmangled extern "C" it works, but it is not possible to upgrade the cycle to "native" Rust symbols. A single-target binary crate would avoid this pitfall.
2. Cargo only supports linking native libraries for lib targets, which means that code that ends up in the bin target cannot reference symbols from native libraries.

Point 1 is addressed to either option you sketched; point 2 only improves when main.rs is made trivial.

An example of a real-world project which exhibits the cyclic dependency structure mentioned is https://github.com/Old-Man-Programmer/tree -- tree.c contains main(), and it also has a function printit(...) which is not called within tree.c. However, the signature for printit is in tree.h, and unix.c includes tree.h and calls printit.