You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ability to specify the output name for a bin target different from the crate name #1706
As far as I know, the only way to name the output of a bin target is through the name attribute of a bin section.
This, however, sets both the crate name and the output name.
It seems too restricting that the output name of an executable should be a valid crate name.
For example, it cannot contain spaces. Cargo also warns if it's uppercase, because crate names are lowercase by convention.
Rustc with the -o FILENAME option allows to set any arbitrary filename for the output.
If there is already a way to do this with cargo, it should be better documented, as I couldn't find it.
Reacted by tyleo, Nick Renieris, Shockingly Good, Alexander Bulaev, horrorho, Forrest Fleming, Vanessa McHale, Utkarsh Upadhyay, Preston Carpenter, Behnam Esfahbod and 84 more
@matklad yep, and I deleted my comment as it was incorrect; sorry about the noise; misunderstanding on my part when looking for a solution for my problem. (And feel free to hide this comment.)
Would love to see the ability to specify the name of the inferred main.rs binary target. Just a note, you can:
mkdir src/bin
mv src/main.rs src/bin/foo.rs
and the main bin will not longer be auto-discovered and cargo run will run the sole foo bin target without any other config. Would be nice to be able to do something like:
While I agree that it would be nice for aesthetics and/or convenience, personally I want this feature so that I can produce executables that have names not allowed by the current scheme (e.g. en% and de%).
The name applies to the auto-discovered main target (no duplicate binary target is created).
Unfortunately if the name isn't in snake case (or kebab case) you'll get a warning (crate `X` should have a snake case name), but I want to name my executable file in pascal case. Hoping for a workaround other than disabling the warning or changing the name.
We used to have application binaries called foo.cli and foo.gui and unfortunately we can't switch to rust because this issue breaks backwards compatibility. All in all it's kinda silly that applications have a crate name tho, it's not like that's ever gonna be exposed anywhere, and it's not like there are macros to get the crate name at compile-time or anything.
Why not just set the crate name the same for all applications, and/or remove the concept of crate name from rust applications?
Reacted by Wafelack, David Cowden and Michael Leonard
You can actually get the crate name at compile time. And crate names for application aren't « silly » as you say, they are necessary for crates.io (for both installation and searching.).
Unfortunately if the name isn't in snake case you'll get a warning (crate `X` should have a snake case name), but I want to name my executable file in pascal case. Hoping for a workaround other than disabling the warning or changing the name.
This isn't true (entirely), I have the following and I do not get any errors when calling cargo run:
[package]
name = "krate_name"
[[bin]]
name = "krate-name"path = "src/bin/krate_name.rs"
Unfortunately if the name isn't in snake case you'll get a warning (crate `X` should have a snake case name), but I want to name my executable file in pascal case. Hoping for a workaround other than disabling the warning or changing the name.
This isn't true (entirely), I have the following and I do not get any errors when calling cargo run:
[package]
name = "krate_name"
[[bin]]
name = "krate-name"path = "src/bin/krate_name.rs"
It seems to also support kebab-case.
Yeah I forgot about that, edited. The warning explicitly says snake case, so I guess that's an oversight. Snake case is preferred over kebab case IIRC.
We'll probably want to only allow this on [[bin]] and [[example]] targets to start off. Configuring the file stem of a [lib] target should likely be an error
I need this feature for a [lib]. My use case: I write plugins for other software in Rust, which are technically shared libraries (crate-type = ["dylib"]: .so files, as I'm workig on Linux), but should be named something.plugin instead of libsomething.so.
Such a good suggestion. I'm writing a plugin atm and I have a post-install script that renames the resulting "lib", since it's prefixed with lib and there doesn't seem to be a direct way of telling cargo to just use the name field. Strange that it does this by default.
Activity
alexcrichton commentedon Jun 11, 2015
I think this can be solved with
cargo rustc(a relatively new subcommand), so I'm going to classify this as a docs bug.crumblingstatue commentedon Jun 11, 2015
How does
cargo rustcsolve this problem?What I'm thinking of is the ability to specify the output name of the executable in
Cargo.toml, so everyone who compiles it gets that executable name.alexcrichton commentedon Jun 11, 2015
Yes
cargo rustcwould not allow you to encode the value in Cargo.toml, cargo does not currently allow that level of configuration.ebkalderon commentedon Jan 5, 2016
I would like to express interest in this feature as well.
cutewalker commentedon Jul 11, 2016
yes, +1 for this feature
VelocityRa commentedon Jul 29, 2016
One whole year and still nothing...
iddm commentedon Nov 14, 2016
+1 for this feature.
Lakier15 commentedon Feb 1, 2017
+1 for this feature
Boscop commentedon Apr 9, 2018
Yes, please :)
matklad commentedon May 6, 2018
@brettcannon binary can have a name different from the name of he package, you can see it in Cargo toml in a [[bin]] section with the name key
brettcannon commentedon May 6, 2018
@matklad yep, and I deleted my comment as it was incorrect; sorry about the noise; misunderstanding on my part when looking for a solution for my problem. (And feel free to hide this comment.)
tzaeru commentedon May 16, 2018
+1.
I wouldn't want to change my pretty
to
20 remaining items
dcow commentedon Feb 2, 2021
Would love to see the ability to specify the name of the inferred main.rs binary target. Just a note, you can:
and the main bin will not longer be auto-discovered and
cargo runwill run the solefoobin target without any other config. Would be nice to be able to do something like:for aesthetics.
dragonmaus commentedon Feb 2, 2021
While I agree that it would be nice for aesthetics and/or convenience, personally I want this feature so that I can produce executables that have names not allowed by the current scheme (e.g.
en%andde%).dcow commentedon Feb 2, 2021
Just tested and you can also:
The name applies to the auto-discovered main target (no duplicate binary target is created).
kotx commentedon Feb 14, 2021
Unfortunately if the name isn't in snake case (or kebab case) you'll get a warning (
crate `X` should have a snake case name), but I want to name my executable file in pascal case. Hoping for a workaround other than disabling the warning or changing the name.SoniEx2 commentedon Feb 21, 2021
We used to have application binaries called foo.cli and foo.gui and unfortunately we can't switch to rust because this issue breaks backwards compatibility. All in all it's kinda silly that applications have a crate name tho, it's not like that's ever gonna be exposed anywhere, and it's not like there are macros to get the crate name at compile-time or anything.
Why not just set the crate name the same for all applications, and/or remove the concept of crate name from rust applications?
Wafelack commentedon Feb 23, 2021
You can actually get the crate name at compile time. And crate names for application aren't « silly » as you say, they are necessary for crates.io (for both installation and searching.).
mainrs commentedon Mar 7, 2021
This isn't true (entirely), I have the following and I do not get any errors when calling
cargo run:It seems to also support kebab-case.
kotx commentedon Mar 7, 2021
Yeah I forgot about that, edited. The warning explicitly says snake case, so I guess that's an oversight. Snake case is preferred over kebab case IIRC.
whereistejas commentedon Jun 26, 2021
Hi everyone,
If possible I would like to take up this issue. Based on the discussion above, we can summarise the requirements as follows:
[[bin]]section along withnamecalledfilename.namewill allow us to set the name of the crate.filenamewill allow us to set the name of the binary.[[bin]]and[[example]].@alexcrichton @ehuss please correct me if I'm wrong about the above requirements.
@rustbot claim
Auto merge of #9627 - whereistejas:many-bin-names, r=ehuss
ehuss commentedon Aug 11, 2021
Closing as this is now implemented via #9627, and stabilization tracked in #9778.
eureka-cpu commentedon May 16, 2024
Such a good suggestion. I'm writing a plugin atm and I have a post-install script that renames the resulting "lib", since it's prefixed with
liband there doesn't seem to be a direct way of telling cargo to just use thenamefield. Strange that it does this by default.