unable to create run or debug configurations

[rustdt]

unable to create run or debug configurations

[bruno-medeiros]

Workaround is: just add an empty tests/dummy.rs file to your crate.

[bruno-medeiros]

Right, so I tried this again on an empty project, and yeah, you're right it wasn't building the bin targets. It only builds if the crate has test targets. I've reopened: rust-lang/cargo#2495

[bruno-medeiros]

You're not meant to start cargo for the launch configurations. (for starters, you won't be able to debug your executable that way). Just put the path to the executable that cargo builds. If no executable exists yet, just do a build first.

[genodeftest]

I would expect RustDT to take a path to the main.rs file, build and run it. Why should I manually build the project?
In the Java Perspective, when I click on "Run" it builds and runs the currently opened Java file (if it has a main() function) or the last known run configuration from the same project. When I click on "Debug" it builds and runs the same but with debugging options and opens the "Java Debug" Perspective.

What I would like RustDT to do is:
When I click on "Run" automatically start the last run configuration for this project. If not present create a run configuration for the current file (if it has a main) or the current project. Then build and run the project.
I do not want to build my project manually with some cli command.

[bruno-medeiros]

You don't have to build your project manually with some cli command, you built it from Eclipse. And you only need to do it once, to configure the executable path in the launch configuration.
I agree it would be better for RustDT to configure this, but it's not trivial to implement.

[bruno-medeiros]

Created #34

[genodeftest]

I don't think I understood your answer until now.
The "Program Path" is the target where RustDT will put the built executable. It needs this path because it can't figure out (yet) what it will if using some rustc/cargo stuff internally. So "Program Path" could have a tooltip "This is where your executable will be put".
Did I understand you and the UI now?

[bruno-medeiros]

Yes, "Program Path" is a project-relative path to the executable to run. Typically this would be the executable that cargo builds (target/debug/hello_world.exe for example), but it can be any executable, since the launch functionality does not use cargo/rustc.

[genodeftest]

Ah, so you can (and should be able to) use e.g. shell scripts to start your application.

[bruno-medeiros]

Err, what? You can't do that because a shell script is not an executable.
Why would you want to do that anyways? That doesn't seem to make sense.

[snuk182]

Did not find a suitable ticket for my question, so asking here.
Trying to run/debug app ends with the error "Executable file (C:\rustworkspace-win\standalone\target\debug\standalone.exe) doesnt exist."
Indeed. Something adds a sort of a hash to the filenames (e.g. standalone-1234567890abcdef.exe), so the standard launcher cannot find the correct exe. Is there a way to disable this hashing?

[bruno-medeiros]

The filenames with hashes are the executables for the crate test targets, they are not the actual "main" executable of your crate. Your "standalone.exe" file should have also been created. Which build command did you use to build your Cargo project?

[snuk182]

Just pressing either Ctrl+B or Menu - Project - Build.
I'm on fresh RustDT (pulled yesterday) + Eclipse Neon (Mars has the hashes as well).

[bruno-medeiros]

Check the Rust Tools log in the Console view to see what command was invoked, and also what the output was. Default command should be cargo test --no-run, which should create the crate binary target executable. If not, try running cargo build in the command line.

[snuk182]

Ah. I see.
cargo build produces properly named binary. cargo test produces hashed temporary build.
rust-lang/cargo@27efa7b
I can change this in project settings. But should not it also use build as default?

[bruno-medeiros]

The thing is cargo test --no-run produces the bin-target executable in my machine. It should not be necessary to change to cargo build. Which Cargo version are you using?

[snuk182]

cargo 0.12.0-nightly (5716f32 2016-06-29)
Rust nightly 1.11

[bruno-medeiros]

I'm on cargo 0.11.0-nightly (259324c 2016-05-20) (Rust 1.10) . I don't understand, it should work. Maybe it's a bug with Cargo 0.12.0 ? cargo test --no-run is supposed to generate all targets, not just the test ones: rust-lang/cargo#2495

[blairjam]

I'm having this same issue where cargo test --no-run does not build all targets. So the test target is built, and then Eclipse goes to run the bin target, but it is not there. Looking through your issue created on cargo's repo(rust-lang/cargo#2495), it looks like you were able to build all targets with cargo test --no-run, but that isn't the case for me.

[MetaCrawfish]

I am also experiencing this issue with (using cargo 0.11.0-nightly (259324c 2016-05-20) with rustc 1.10.0 (cfcb716cf 2016-07-03)). This was installed on Windows 10 64-bit using the default "rust-1.10.0-x86_64-pc-windows-gnu.msi" installer provided on the main Rust website.

Running "cargo test" will generate a .exe file with the hash at the end (e.g. hello_world-177716321ff31a5c.exe ) as part of the test target, but will not generate the normal .exe without the hash from the bin-target. This happens through the raw command line, not just in the IDE, so it seems like an issue with Cargo rather than RustDT (so it may be worth re-opening rust-lang/cargo#2495 ).

As a workaround, you can change the Rust Build Targets for a project to use ${CARGO_TOOL_PATH} build rather than the default ${CARGO_TOOL_PATH} test --no-run. It may be worthwhile making build the default command so that the Eclipse "Run" button works out of the box for new users, and more experienced users could change it to test --no-run manually for more complex projects. (Of course, if Cargo gets updated so that test --no-run generates the normal bin-target's .exe files again, then this wouldn't be necessary).