Per crate memory.x file in a workspace.

[rukai]

In my project I have a bin crate for a bootloader which jumps to the firmware and a bin crate for the actual firmware. I need to provide both of these projects with a unique memory.x file so that the binaries do not overlap when flashed.

I am happy to provide a PR for this, but there are a few ways to provide this so I wanted to get some feedback first. We could:

• Only get memory.x from actual bin crates not from the workspace crate and fail to build a bin crate if it has no memory.x
• Get memory.x from the actual bin crates but fall back to the workspace crate memory.x if a bin crate has no memory.x
• Something else maybe...?

[rukai]

After some research it appears this needs to be solved on the users end. Although if we could change upstream to make this more convenient that would be great.

I ended up with a per binary crate build.rs exactly the same as the one at: https://github.com/japaric/f3/blob/b40415b4c4f7e76bdf27dcb570bf961c75cb707b/build.rs

This solves my problem so feel free to close this issue, or it can be kept open if there is a better solution that could be done upstream.

[adamgreig]

I think your conclusion is basically right: we don't control where the linker gets the memory.x from, it searches its own search path, which starts with the current working directory (the workspace or crate if not in a workspace) and then goes to the OUT_DIR. When users are building a not-in-workspace crate or have one memory.x shared by all crates in a workspace, no build.rs script is required, but otherwise one such as your example is.

The only thing we've discussed that could be a nicer solution is to revamp the linker script entirely so that it's generated at build time by a function inside the user's build.rs which could then also specify other sections and so forth, but that's some way off.

Thanks for reporting the issue and your conclusions!