-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo rustc subcommand #595
Comments
I'm not totally sold on the utility of this command due to the recompiling dependencies restriction, but I'm curious what others think about this. |
A pain point for me is debugging macros. Generally, I need to do a Having a "build deps and pre-fill the command line" command would be lovely. |
I think this or something like it should happen. Personally, I'm still waiting on a way to pass a linker script to the linker without writing a custom Makefile (and defeating a lot of the things that make cargo so nice to use). I'm still fairly new to rust/cargo, so I may be overlooking something. The problem I'm running into is that cargo is almost too high level for such a low level language. |
This seems like what we want. So, As long as the usual link args are available I think we can make this work :) |
We have worked around this for now by instead setting the linker to be a shell script that manually invokes everything we need. |
Such a function would be really helpful. Otherwise it is almost impossible to use any rustc flag that is not exposed by cargo. It could be also usefull for IDEs to be able to run a simple |
I've already found myself using the verbose flag of cargo to obtain the rustc call, and then alter its flags to obtain, e.g., the LLVM bytecode or similar. A command like this would make that much easier. |
@RalfJung Rust team members have told me that they replace the rustc binary with a shell script that calls out to the binary itself in order to add extra arguments, as a workaround for this lack of functionality when debugging. |
Thanks :) . A trick I already used on other occasions, but it's
certainly worth remembering that it also helps here.
|
Attempting to get better rust support into Emacs's Flycheck has really shown me the usefulness of this -- this would make my life much, much easier. |
I concur with @GBGamer - this is something really useful for editors and IDE's, as well as some refactoring and analysis tools. I'd like to see this implemented as it would enable Emacs' Flycheck to use cargo and properly handle dependencies. |
+1, the sooner this gets implemented the better. |
## Work in progress I have followed issue #595 for a while now. I hope that this PR can solve it, after it's done of course. @alexcrichton: on IRC the other day, you suggested adding a `Vec<String>` to the `CompileOptions`. I have done this, but wasn't sure what the best way to identify the correct `Target` would be, so currently everything gets compiled with the additional arguments. I considered adding a `Target` structure to the `CompileOptions` as well, and then in `cargo_rustc::build_base_args` only append the arguments if the `Target` matches. What do you think about this? Is there an easier way of figuring out the correct `Target`? r? @alexcrichton
Thoughts?
The text was updated successfully, but these errors were encountered: