You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Arguably this is a problem with cargo itself, but you can work around it easily in the shell.
Setup
create a cargo workspace
add a subworkspace
in the subworkspace, create a .cargo/config with, eg [build] target = "thumbv6-none-eabi"
try to build the subworkspace in emacs.
Results
You'll get a bunch of linker errors. I realize the setup is pretty vague, but you can find a sample project that has this problem here
Investigation
The reason this happens is because the various cargo commands, spawned from cargo-process--start specify default-directory as (or (cargo-process--workspace-root) default-directory), where the latter default-directory points to the sub-workspace root.
If the let binding on default-directory is removed from the subsequent compilation-start call (thus pointing default-directory at the result of cargo-process--project-root), the sub-workspaces will compile correctly.
I assume there's a reason for overriding default-directory before calling compilation-start, but I don't know what it is, as everything appears to work correctly without it, with the added bonus that the problem described above goes away.
The text was updated successfully, but these errors were encountered:
I honestly don't remember what the reason what to override default-directory. It could be that it had something to do with sub workspaces but I don't know.
I haven't used Rust in a long time and I myself am not using this Emacs package, so it's very hard for me to maintain it.
Arguably this is a problem with cargo itself, but you can work around it easily in the shell.
Setup
[build] target = "thumbv6-none-eabi"
Results
You'll get a bunch of linker errors. I realize the setup is pretty vague, but you can find a sample project that has this problem here
Investigation
The reason this happens is because the various cargo commands, spawned from
cargo-process--start
specifydefault-directory
as(or (cargo-process--workspace-root) default-directory)
, where the latterdefault-directory
points to the sub-workspace root.If the
let
binding ondefault-directory
is removed from the subsequentcompilation-start
call (thus pointingdefault-directory
at the result ofcargo-process--project-root
), the sub-workspaces will compile correctly.I assume there's a reason for overriding
default-directory
before callingcompilation-start
, but I don't know what it is, as everything appears to work correctly without it, with the added bonus that the problem described above goes away.The text was updated successfully, but these errors were encountered: