tracking issue: cross compilation

[nrc]

The RLS should work properly with cross-compiled crates, this mostly means working properly with Rustup and Xargo

• - std libs data for correct target (discussed in Easy to use indexing of std libs #88)
• - run Xargo as well as Cargo (discussed in Support cross-compiling and custom targets #104)

cc #104
cc @Xanewok

[nrc]

To address the first item, I think we need to pass the target from the RLS to rls-analysis so that we load the correct version of the std libs save-analysis data.

[ketsuban]

#88 was closed, should the first box in the OP be checked or is there more to it than that?

[nrc]

Although we do have the info available from indexing std, we still don't use the correct version when compiling for a target other than the host.

[nrc]

This is where to fix that: https://github.com/rust-lang/rust/blob/master/src/tools/build-manifest/src/main.rs#L348 It should be treated more like std libs, just below.

[parasyte]

This is related. I started a new project that contains two different crates, with both expected to be compiled for different targets. I could split the crates out into separate repos, but I don't think they will ever be used apart. One is a build tool that is compiled on the host (Linux, Windows, macOS). And the other is cross compiled for an embedded system.

The trouble is RLS only has a notion of using one target triple for every crate in the project.

[marmistrz]

Currently we have the rust.target configuration option, which seems to partially do the trick for me (only for compilation, not for hover hints)

[jacobrosenthal]

Forgive the dumb question, but why does target have to be specified separately from .cargo/config

[marmistrz]

@jacobrosenthal I meant the configuration option of the VSCode extension.

[jacobrosenthal]

This may or may not be the place or this, but Im asking why rls can't harvest the target from the existing .cargo/config instead of me having to duplicate which is obviously error prone. Im sure theres a reason, but curious what it is.

[marmistrz]

@jacobrosenthal I don't understand what you mean. It's as simple as "rust.target": "x86_64-pc-windows-gnu", in the vscode settings.json. It's equivalent to cargo build --target=$TARGET

[jacobrosenthal]

Cross compilers, especially embedded, already hardcode our target in once place, .cargo/config It tends to look like this ``` [build] target = "armv7-unknown-linux-gnueabihf" [target.arm-unknown-linux-gnueabihf] linker = "arm-linux-gnueabihf-gcc" ``` Its disappointing to hardcode the same value twice. Im just curious the technical challenge that requires rls to not be able to read .cargo/config and require a new target setting

…

On Wed, Jul 24, 2019 at 12:24 AM Marcin Mielniczuk ***@***.***> wrote: @jacobrosenthal <https://github.com/jacobrosenthal> I don't understand what you mean. It's as simple as "rust.target": "x86_64-pc-windows-gnu", in the vscode settings.json — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#309?email_source=notifications&email_token=AADPI5CW24PK3U3VV5HWVVDQA77R7A5CNFSM4DK5ELW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2VNS4Y#issuecomment-514513267>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADPI5ERARQSOOCKFWHUB43QA77R7ANCNFSM4DK5ELWQ> .

[rubberduck203]

It's not desirable to have to hard code the target.
When unit testing embedded code, you often want to run your tests (and therefore compile at least a portion of your production code) on your development machine.
This means you cannot set a target in the .cargo/config file, it must be specified on the command line.

Please see the cortex-m-quickstart example linked below for an example of why we can't rely on a build target being specified in .cargo/config.

https://github.com/rust-embedded/cortex-m-quickstart/blob/master/examples/test_on_host.rs

[jacobrosenthal]

but if it already is...

…

On Wed, Nov 13, 2019 at 11:29 AM Christopher McClellan < ***@***.***> wrote: It's not desirable to *have* to hard code the target. When unit testing embedded code, you often want to run your tests (and therefore compile at least a portion of your production code) on your development machine. This means you cannot set a target in the .cargo/config file, it must be specified on the command line. Please see the cortex-m-quickstart example linked below for an example of why we can't rely on a build target being specified in .cargo/config. https://github.com/rust-embedded/cortex-m-quickstart/blob/master/examples/test_on_host.rs — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#309?email_source=notifications&email_token=AADPI5G4DMWTK2PJ2WZXIJLQTRBSPA5CNFSM4DK5ELW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED7FIXY#issuecomment-553538655>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADPI5GDPX3KSPUIEEVIW6TQTRBSPANCNFSM4DK5ELWQ> .

[rubberduck203]

Sure, if it already is, then it'd be nice to use it.
I'm just seeing some things in the ecosystem that are assuming you are hard coding it into your config.

[VizorKit]

I have added this to my .vscode/settings.json file.

{
    "rust.target": "thumbv7em-none-eabi",
    "rust.all_targets": false
}

I have added this to my .cargo/config file.

[build]
target = "thumbv7m-none-eabi"

And I am still getting this error.

** EDIT **
I switched to using "riscv32imac-unknown-none-elf" for all these settings. Since that is what type of binary I really wanted to build. I was just trying to follow this guide. https://docs.rust-embedded.org/embedonomicon/memory-layout.html

It's proving to be quite out of date, but at least I can get started there. I am no longer receiving the error about the target missing, but it is still complaining about the below.

[MozarellaMan]

@VizorKit Did you find a solution? I'm having the same problem