Passing compiler flags to the target compiler, on the command line

[oowekyala]

So the Rust build tool Cargo has a very useful feature called profiles. A profile is a collection of settings applied to build tasks, mostly to configure the optimisation level of the produced binary. The most important profiles are dev and release:

• with the dev profile, most optimisations are disabled, the binary contains all debug symbols, and debugging assertions are included. This is the default when you run cargo build for instance, as it's the one you'd want to use in a development setup (eg when running tests).
• with the release profile, all optimisations are turned on, debugging assertions are removed, and it's not uncommon to strip debug symbols to make the binary smaller. The build can be significantly slower. This profile should be used in production, and eg when running benchmarks. You can use it with eg cargo build --release

This 2-profiles model matches nearly all development flows, as the improved compile times of the dev profile are useful during development, and you infrequently need to build a highly optimised "release-ready" binary.

During development of the Rust target, I initially setup cargo to use the --release profile always, to enable optimisations. But this was a bad idea, as I realised much more recently that many debug assertions built into the runtime were being stripped from the test binaries.

In #628 I changed that behavior to invoke the rust compiler with dev profile by default, using a target property to control that:

cargo-profile: RELEASE

I think it's not a good long term solution, as I think the choice of release vs debug build should be made outside of the program source. The program is the same, only the deployment environment is different.

However, the CLI of lfc doesn't have an option to pass arguments to the target compiler, so we can't do for instance

$ lfc --compiler-args ' --release' Snake.lf

to pass the --release flag to cargo.

I think we should at the very least add such an option to LFC's CLI. Maybe it might even make sense to make LFC adopt the same model as Cargo, ie, have a built in --release flag which enables (target-specific) optimisations. Wdyt?

[cmnrd]

In the cmake based targets (C and Cpp), there is a target property called build-type. This can be set to Release, Debug, RelWithDebInfo and MinSizeRel. In a sense, these are the "profiles" provided by cmake. Do you think it would make sense to use the same property for rust, and restrict its possible values to Release and Debug?

With regard to the cli argument, I think that many of our properties should actually be CLI arguments (or configuration options in an Epoch project). I would be absolutely in favour of introducing --build-type as also the other targets would profit from this.

[oowekyala]

Thanks, I didn't know about that property :) Yes I think it would definitely make sense to reuse build-type for rust. We could actually also support RelWithDebInfo and MinSizeRel, even if they're not default cargo profiles, it's very little setup to add new profiles afaik.

[oowekyala]

One thing is that this target property has "Release" as default, which I don't really agree with... I think at least the Rust default should be Debug, in line with Cargo. Maybe it makes sense to use that as a default for all targets? I would think release builds are rarer than debug builds... but maybe the workflow with CMake is different

[cmnrd]

I am not sure how it works for Cargo, but in CMake "Debug" means no optimization at all. I don't think this is a good default. I usually use release builds and only use Debug if I really want to debug some issue.

[oowekyala]

For reference, the dev profile in Rust also disables all optimisations. I think Rust developers will expect this, so it's not a problem. It's fine to have target-specific defaults I think

[cmnrd]

So do you think we should have a different default for C++ than for Rust?