Use cargo-make to build the packages

[jscatena88]

As mentioned in #33, here is a first pass at cargo make integration, Running cargo make in the workspace root will build every package with the appropriate target (it will also run rustfmt by default). cargo make can also be run in individual packages to build just that package. This only scratches the surface of what the tool can do(e.g. it can also be used to install dependencies like flip-link, it can be used as part of your CI, etc. )

You will need to install cargo make to make use of the changes.

I also added a a more understandable compiler error if someone attempts to build fl16-inputmodules with mutually exclusive features enabled.

[JohnAZoidberg]

Thanks! This is pretty cool :)
Can it also work for running commands?
Currently it's quite cumbersome to run the inputmodule-control program:

# Linux
cargo run --target x86_64-unknown-linux-gnu -p inputmodule-control

# Windows
cargo run --target x86_64-pc-windows-msvc -p inputmodule-control

[JohnAZoidberg]

And can I apply the profile options listed here only to the firmware workspace members?
#19 (comment)

[jscatena88]

running cargo make and then cargo make build-release in the top level directory will also work, it will essentially run all the tasks you have listed out here, as well as a bunch more that are part of the default dev-test-flow task, but that can be customized; to, for instance, not run any tests. I would also definitely recommend looking through the all the rest of the pre-defined tasks in the link above, it provides a bunch of sane defaults that can be tweaked as necessary to support your use case, including things like building binaries for release, or CI workflows.

In general, the default behavior when run you run cargo make in a workspace root is to go down into each workspace member and run the task that was called.

[jscatena88]

It should be easy enough to customize the build tasks for each package to call the correct build profile by default, maybe place the non-firmware profiles behind names like profile.release-application and then in the inputmodule-control Makefile you could appropriate env.BUILD_TYPE the way I did in the top level Makefile. i.e.

[tasks.build-release]
env.BUILD_TYPE = "--release-application"

[tasks.build]
env.BUILD_TYPE = "--dev-application"

When you add a task in one of your makefiles it will only override the fields you provide overrides for by default so everything else about the build and build-release tasks would be left alone. (to override everything you add clear = true)

Note all of this is off the cuff and untested for now, I don't have access to my dev machine at this exact moment

EDIT: I also came across CARGO_MAKE_CARGO_PROFILE that looks like it ties in somehow

[jscatena88]

Running commands should also be fairly trivial, just add something to the effect of

[tasks.run]
command = "cargo"
args = [
    "run",
    "--target",
    "${CARGO_MAKE_RUST_TARGET_TRIPLE}",
]

in the inputmodule-control Makefile. You should then be able to run cargo make run in the inputmodule-control directory or in the root with --cwd inputmodule-control (as above this is currently untested)

[JohnAZoidberg]

Suggested change

	TARGET_TRIPLE = "x86_64-unknown-linux-gnu"
	TARGET_TRIPLE = "${CARGO_MAKE_RUST_TARGET_TRIPLE}"

Awesome, this works!

[JohnAZoidberg]

Okay, I'm happy with it, thanks a lot @jscatena88!

[jscatena88]

Cheers! I'm glad it was helpful