Passing more flags to rustc

[vosen]

This is kind of a followup to #60. I've been eyeing cargo integration with Visual Studio and after asking on IRC I want to propose more flags for inclusion in Cargo.toml:

1. --cfg, it's a commonly used rustc feature
2. --C or at least --C link-args. It's required for passing -mwindows (compile as a Windows Desktop app, no console output) and for passing resources (icons, executable manifests) to the gcc.
3. -W, -A, -D, -F, four lint control flags, projects will want to set stricter/more relaxed baselines across code-base.

[alexcrichton]

As I mentioned in #60, it's unlikely that cargo build will support shipping along arbitrary compiler flags. That being said, here's what cargo build will likely support:

1. --cfg will manifest itself with features
2. -C will definitely be supported, but probably not -C link-args. The -mwindows flag may be something that rustc should pass by default? What does it do?
3. These will likely not be supported as they're what the in-crate attributes will predominately support.

Also as mentioned in #60, the plan is have fine-grained subcommands which you can script yourself. The idea is that cargo build is just a high-level wrapper around these subcommands. With these you'll be able to pass whatever you want, they sadly just don't exist right now (still figuring out what exactly we want).

[vosen]

I'm unclear on the subcommands. Last comment in #60 mentions no arbitrary flags in the manifest/cargo build, but I assume that means "no arbitrary flags in build section but all kinds of arbitrary flags in rustc section", so something like

[rustc]
flags="-C link-args icon.res"

(or whatever syntax will be for subcommands) will be fine. Am I right? If so, I'm perfectly happy with subcommands and closing this issue.

As for the flags. No, -mwindows shouldn't be default. It's for desktop apps like firefox. It sets pe32 subsystem to gui, which means that app doesn't get console. -C link-args is needed for pasing resources: icon, app manifest (though I've just managed to emulate it with #[link(name=..., kind="static")] and empty extern, but I don't think that's very intuitive)

[alexcrichton]

By subcommands, I mean where the cargo commands themselves are all built on a common set of primitive commands. You wouldn't personally use the subcommands that often as they'll be fairly restrictive and may not do much, but they're available to you whenever you need to configure your workflow.

So, for example, cargo build would not take arbitrary flags, but a possible cargo rustc may indeed take many flags to pass through. The downside would be that cargo rustc doesn't actually build or fetch dependencies, it just assumes that they're all in-place.

Does that make sense?

[vosen]

Yes, it does.

[alexcrichton]

#595 is an example of a subcommand which may help here, I'm curious about opinions on it!

[eminence]

Slightly related to this is the issue of finding system libraries. As an example, my libcurl require a -L argument to be passed to rustc, so that rustc can find the library. At the moment there is no good way to tell Cargo to tell rustc where to find system libraries. This could be solved in this issue (by allowing me to explicitly pass a -L option). Or this might be solved in a more specific way (maybe having Cargo honor $LDFLAGS or something similar)

[dutt]

I'm curious about this as well since I'd like to sometimes pass the -g option to run the application through gdb.

[tomjakubowski]

Cargo passes -g in the dev profile now by default, which is used when you do a non-release cargo build.

If you wanted to include debugging symbols in a release build, you could set debug = true on the release profile.

http://doc.crates.io/manifest.html#the-[profile.*]-sections

[ghost]

I'd like to control optimization in Cargo.toml:

$ rustc src/lib.rs -O --test; ./xxhash --bench

test xxh32::bench_64k_oneshot       ... bench:     17632 ns/iter (+/- 87) = 3716 MB/s
test xxh32::bench_long_str          ... bench:       169 ns/iter (+/- 2) = 2639 MB/s

$ rustc src/lib.rs --opt-level=3 -C no-vectorize-slp --test; ./xxhash --bench

test xxh32::bench_64k_oneshot       ... bench:     17691 ns/iter (+/- 104) = 3704 MB/s
test xxh32::bench_long_str          ... bench:       172 ns/iter (+/- 3) = 2593 MB/s

$ cargo bench

test xxh32::bench_64k_oneshot       ... bench:     41706 ns/iter (+/- 42) = 1571 MB/s
test xxh32::bench_long_str          ... bench:       336 ns/iter (+/- 7) = 1327 MB/s

[ArtemGr]

FYI, ShowWindow with SW_HIDE can be used as a workaround for the lack of "-mwindows".
Example: http://stackoverflow.com/a/29764309/257568

[wizeman]

It seems that cargo either passes -g to rustc (when debug=true) or --cfg ndebug (when debug=false).

Personally, I'd really like my release build to have both -g and --cfg ndebug, because I really care about runtime speed (i.e. I don't want debug_assert!() macros to run in my release build) and I care about being able to debug my programs, but I don't care about the size of the resulting binary.

It seems that I cannot do this with the current cargo manifest format, but if I could control which options to pass to rustc, then I could easily do it.

[nstoddard]

Unless something like this is implemented, starting in beta it will probably become impossible to use Cargo to compile a program with -mwindows, at least without using the hide_window workaround described above. We really shouldn't have to use a workaround like that. Plus, that technique doesn't work for specifying icons. As far as I can tell, there's no alternative to link_args for that.

Currently you can use the #[link_args] attribute for this, but I'm pretty sure it'll stop working in beta (since it's behind a feature gate). Without Cargo support for link_args, you'll have to run rustc directly in order to use its -C link_args option. I don't think we should force people to run rustc directly if we don't have to.

[alexcrichton]

@nstoddard using -C link-args isn't necessarily super stable and we would probably want a better solution for passing -mwindows to the linker regardless (e.g. what happens when it starts being linked with msvc instead of gcc?).

[deontologician]

1. --cfg will manifest itself with features

@alexcrichton could you expand on this? I would like to have different features compile with different --cfg options enabled, but it doesn't seem possible now

[alexcrichton]

@deontologician for each activated feature foo Cargo will pass --cfg 'feature="foo"'. More information can also be found here: http://doc.crates.io/manifest.html#the-[features]-section

[sfackler]

@alexcrichton you'd still want to pass other kinds of cfgs to e.g. disable logging with --cfg log_level="error"

[alexcrichton]

Ah yes good point, features certainly don't cover all the use cases, just some :)

[larsbergstrom]

We have a few additional scenarios from Servo:

1. Debugging perf regressions in rustc, so we'd like to be able to add -Z time-passes and -Z time-llvm-passes to all rustc invocations, no matter which of the various feature targets we're using.

2. Probably being able to pass -F to forbid a certain class of lints / overrides, unconditionally, across all feature targets

3. Tweaking level of debug info at every optimization level

Note that those are off the top of my head, just things we've wanted to do in the last couple of weeks. I would much rather see you prohibit the specific rustc flags that you don't want people to pass through rather than one-by-one enable subsets from the vast array of flags that do not jeapordize your platform-independent compilation goals.

[Manishearth]

cc me

[alexbool]

and me

[gsingh93]

1. --cfg will manifest itself with features

I've always thought of features as a subset of cfg, not the same thing. There could be some cfg options that aren't declared as features in a Cargo.toml file.

[aidanhs]

Interested in this.
I'm currently playing with statically linked binaries (i.e. so ldd returns not a dynamic executable) and have it working, but it requires both manipulation of rustc arguments and custom invocation of the system linker. So I guess this extends a little beyond the current issue description.
Is cargo intended to allow building every possible rust project, or is is a 99% thing?

[gsingh93]

Should this be closed now that #595 is implemented?

[alexcrichton]

I believe so, thanks @gsingh93!

@aidanhs you may be interested in the MUSL support that was recently added, but it looks like you already ran across it elesewhere :)

[tiffany352]

Why can't cargo just have an option for setting the subsystem and providing resource files, if uninterested in allowing arbitrary linker flags to be passed? Is there an ideological preference against platform-specific options in Cargo.toml?

cargo rustc is insufficient for this task. Setting options like the subsystem and providing resource files are something you want to do as part of the normal build process, when you run cargo build. It's not an esoteric feature, it's something that is frequently done on Windows. Almost all of the GUI applications you will use on Windows are win32 subsystem, instead of console subsystem. It is inappropriate for desktop applications to use the console subsystem, because it creates a spurious and distracting console window.

Currently, setting the subsystem is usually attained by creating a custom script which wraps the linker, and then telling cargo to use that linker with .cargo/config. This is not a good solution.

Cargo could do something like this instead:

[windows]
subsystem = "windows" # remove the console, set entry point to WinMain
entrypoint = "default" # override entry point so that the user does not have to write a WinMain
appcontainer = false # windows 8 app store sandboxing
resource = "something" # resource files

[alexcrichton]

Yeah there's a number of locations where that kind of configuration can be located, and some of those actually seem like they'd be more applicable as crate attributes rather than Cargo options (e.g. you'd want them even if you were running rustc by hand)

[ticki]

This was referred in https://www.reddit.com/r/rust/comments/40l6t8/windowed_applications_with_rust/

[dhardy]

@gsingh93 @alexcrichton as I understand it #595 implements the cargo rustc command as a cargo build extension, but doesn't allow passing custom arguments to rustc when testing (aka cargo test)?

[alexcrichton]

@dhardy oh to do that you can do:

cargo rustc --profile test --test foo -- --my-args

[dhardy]

@alexcrichton this still doesn't run tests though, and due to the hashes in the binary names finding the binaries to run is not trivial. Is there an easy solution to build and run all integration tests?

[alexcrichton]

Well for that you may be able to use RUSTFLAGS, but no there's no "pass just this argument to all unit tests and please still run them" command.