avr-rust / delay

arduino-like delay routines based on busy-wait loops
Apache License 2.0
15 stars 11 forks source link

Add /.cargo to gitignore #29

Open bombela opened 2 years ago

bombela commented 2 years ago

For reference, here is the content of my local .cargo/config.toml. With this, the Rust language server will autocomplete for the given target instead of using the host's platform.

[build]
target = "avr-atmega328p.json"
stappersg commented 2 years ago
$ git log --patch | sed --silent '/^commit 2f0f679c/,/^commit/p'
commit 2f0f679c22212933791f298f39f8c1fb450afabb
Author: Nathan Henrie <nate@n8henrie.com>
Date:   Sat Jun 11 06:18:05 2022 -0600

    Set reasonable defaults for cargo config

    This sets `build-std=core` by default and uses the atmega328p as the
    default target. Users will still need to specify alternate targets if
    desired, but it makes the build process much easier for a default case.

diff --git a/.cargo/config.toml b/.cargo/config.toml
new file mode 100644
index 0000000..be8c515
--- /dev/null
+++ b/.cargo/config.toml
@@ -0,0 +1,5 @@
+[unstable]
+build-std = [ "core" ]
+
+[build]
+target = "avr-unknown-gnu-atmega328"

commit 7032d81c5b4bee5ed4a28bc5c4c783a97ba5b7fb

so closing this merge request

bombela commented 2 years ago

This is wrong.

.cargo is local. It should never be committed. That is the reason for existing beyond Cargo.toml.

Default configuration goes into Cargo.toml. Local goes to .cargo.

See documentation: https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

bombela commented 2 years ago

Documentation says:

With this structure, you can specify configuration per-package, and even possibly check it into version control. You can also specify personal defaults with a configuration file in your home directory.

So fair enough, the documentation says you can possibly check it in.

I personally develop mostly against atttiny13a, attiny24a. And I always check compatibility with atmega328(p) (because it is so ubiquitous). Therefor I do change the target often. And I do not want to commit this by mistake.

Reading the doc further, the env var CARGO_BUILD_TARGET takes precedence over the config file. And finally, the --target parameter to cargo/rustc takes ultimate precedence (https://doc.rust-lang.org/cargo/reference/config.html#buildtarget).

I do have to find out how to override this target to rust-analyzer. For now I have simply modified .cargo/config.toml as needed. Maybe there is a better way.

TL;DR: committing .cargo/config.toml is probably fine.

stappersg commented 2 years ago

Maybe there is a better way.

Reopened the merge request to get more exposure for it .

bombela commented 2 years ago

I use neovim with coc. Looks like I can add a local config file, which will then pass --target to rust-analyzer. It does mean I have to remember to keep the local coc files and cargo/rustc command lines (or env var) in sync. I wouldn't expect this crate to require active development after the cycle accurate joins master. But I would imagine this sets the example for other crates targeting avr.

https://github.com/neoclide/coc.nvim/wiki/Using-the-configuration-file#configuration-file-resolve

Anyways, I feel like I am bike-shedding here. I don't want to waste anyone's time.