Handle --crate-name based on --crate-type about cargo-gccrs

[bjorn3]

I don't think gcc can ever be used that way, and it might be a tremendous effort to support it, but I may be completely off base. What we could do however is, in the case of such an invocation where a rlib, dylib and staticlib need to be created at the same time, is invoke gccrs three separate times with the same other options. One time with -o , one time with -shared -o lib.so, and one time with -c .o and an invocation to ar. If it's possible to add multiple type outputs to gccrs and this is what we want, then I'll gladly help. And I agree that this would be the better and less hacky solution.

I think running gcc multiple times would work for now, but at least rustc would likely have problems with that due to the SVH not matching and thus not realizing that they are all the same crate.

[bjorn3]

-o test in gcc is equivalent to the same flag in rustc, which defines the file to write the output too. It doesn't change the crate name even with rustc. A separate -frust-crate-name flag will need to be introduced with -o defaulting to a value based on -frust-crate-name and the crate type.

[CohenArthur]

-o test in gcc is equivalent to the same flag in rustc, which defines the file to write the output too. It doesn't change the crate name even with rustc.

That's true, I'm referring to the fact that cargo invokes us by giving us the --crate-name flag but not the -o one (at least not where I'm at right now).

A separate -frust-crate-name flag will need to be introduced with -o defaulting to a value based on -frust-crate-name and the crate type.

Should this be integrated into the compiler or kept separate? I agree that for the sake of similarity, it would be better to add the option to gccrs. However, you'll need to change the options and adapt the commands even just by using gccrs instead of rustc (for example here --crate-name would need to become --frust-crate-name), so I don't know if it's that really necessary for the compiler. We could simply handle this in this project, what do you think?

[bjorn3]

That's true, I'm referring to the fact that cargo invokes us by giving us the --crate-name flag but not the -o one (at least not where I'm at right now).

Cargo will pass --out-dir and -Cextra-filename when compiling the actual crates. The -Cextra-filename is appended after the crate name and before the extension in the output filename.

Should this be integrated into the compiler or kept separate? I agree that for the sake of similarity, it would be better to add the option to gccrs. However, you'll need to change the options and adapt the commands even just by using gccrs instead of rustc (for example here --crate-name would need to become --frust-crate-name), so I don't know if it's that really necessary for the compiler. We could simply handle this in this project, what do you think?

It is valid to use a different crate name but the same output location when compiling (by moving the crate after the first rustc invocation) and then linking both crates against each other. It is not valid to use the same crate name, but different output locations (ignoring -Cmetadata) The crate name is an integral part of the identity of a crate and doesn't have to match the actual output filename, so gccrs has to support it either way. Also rustc supports multiple crate types at the same time (exposed by cargo through the crate-type array in Cargo.toml, commonly used to get both an rlib and dylib or staticlib at the same time) in which case a single -o won't work.

[CohenArthur]

Cargo will pass --out-dir and -Cextra-filename when compiling the actual crates. The -Cextra-filename is appended after the crate name and before the extension in the output filename.

Yes exactly, the command I'm working on right now is the following:

rustc --crate-name basic_rust_project --edition=2018 src/main.rs --error-format=json --json=diagnostic-render
ed-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=284bf825bb1e6377 -C extra-filename=-284bf825bb1e6377 --out-dir /home/arthur/Git/cargo-gccrs/basic_rust_project/target/debug/deps -C incremental=/home/arthur/Git/cargo-gccrs/basic_rust_project/target/debug/incremental -L dependency=/home/arthur/Git/cargo-gccrs/basic_rust_project/target/debug/deps

Thus, the binary produced has the following path and name /home/arthur/Git/cargo-gccrs/basic_rust_project/target/debug/deps/basic_rust_project-284bf825bb1e6377

Which means we have the following pattern

<outdir>/<crate_name><extra_filename>

My idea was to accumulate those arguments and pass them (as you said) as a single filename to -o. We would then end up with the following format based on --crate-type:

<outdir>/[lib]<crate_name><extra_filename>[.so|.a] (at least on linux)

This also correlates with how gcc is typically used: a single -o option containing output dir, name, and maybe extension (.so|a) and prefix (lib) if creating a (shared) library.

Also rustc supports multiple crate types at the same time (exposed by cargo through the crate-type array in Cargo.toml, commonly used to get both an rlib and dylib or staticlib at the same time) in which case a single -o won't work.

I don't think gcc can ever be used that way, and it might be a tremendous effort to support it, but I may be completely off base. What we could do however is, in the case of such an invocation where a rlib, dylib and staticlib need to be created at the same time, is invoke gccrs three separate times with the same other options. One time with -o <name>, one time with -shared -o lib<name>.so, and one time with -c <name>.o and an invocation to ar. If it's possible to add multiple type outputs to gccrs and this is what we want, then I'll gladly help. And I agree that this would be the better and less hacky solution.

It is valid to use a different crate name but the same output location when compiling (by moving the crate after the first rustc invocation) and then linking both crates against each other. It is not valid to use the same crate name, but different output locations (ignoring -Cmetadata)

That's really interesting! Thanks

The crate name is an integral part of the identity of a crate and doesn't have to match the actual output filename, so gccrs has to support it either way.

Gotcha. Then we'll definitely need to add the option to gccrs, and I'll try to work on it in the scope of this project.