Skip to content
This repository was archived by the owner on Jul 29, 2025. It is now read-only.

Conversation

@obraunsdorf
Copy link

No description provided.

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @therealprof (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Copy link
Contributor

@therealprof therealprof left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that's sufficient. Usually the file looks like:

use std::env; use std::fs::File; use std::io::Write; use std::path::PathBuf; fn main() { // Put the linker script somewhere the linker can find it let out = &PathBuf::from(env::var_os("OUT_DIR").unwrap()); File::create(out.join("memory.x")) .unwrap() .write_all(include_bytes!("memory.x")) .unwrap(); println!("cargo:rustc-link-search={}", out.display()); println!("cargo:rerun-if-changed=build.rs"); println!("cargo:rerun-if-changed=memory.x"); } 
@adamgreig
Copy link
Member

By default the linker will search the crate's directory without needing to be told, so having memory.x in the same place as Cargo.toml works fine; adding a build.rs which only adds cargo:rerun-if-changed=memory.x is enough to rerun the build when memory.x changes in that case. Whether we want/should (re)include that longer build.rs example in the quickstart, I don't know... the only edge case where it can be required is in workspaces or weird build configurations.

@therealprof
Copy link
Contributor

I'm not sure where the more elaborate build.rs is coming from. Also I don't see too much value in a build.rs in general but if we have one it should probably provide the full benefit and not just half. Are there any downsides to providing the full version?

@thalesfragoso
Copy link
Member

thalesfragoso commented Jul 19, 2020

I'm not sure where the more elaborate build.rs is coming from. Also I don't see too much value in a build.rs in general but if we have one it should probably provide the full benefit and not just half. Are there any downsides to providing the full version?

I always use the complex one, but some people did some testing and it seems that the cargo directory is already in the linker search path, so it's unnecessary to copy it somewhere else.

@therealprof therealprof added the nominated Issue nominated as discussion topic for the Embedded WG meeting label Jul 20, 2020
@therealprof
Copy link
Contributor

As discussed in the meeting we should add a comment to explain when and why this might be necessary to give users a good base for a decision whether this is necessary.

@therealprof
Copy link
Contributor

Addressed by #92.

@therealprof therealprof removed the nominated Issue nominated as discussion topic for the Embedded WG meeting label Jul 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.