build fails #61

Closed
opened 2022-01-05 03:20:23 +08:00 by hartytp · 6 comments

Following the build instructions the build fails with an error cannot find macro 'asm' in this scope.

Just needs a single-line fix and the error message is pretty helpful. I guess you're pinning to a particular version of nightly in your build infrastructure, but haven't done that in the build files here?

Following the build instructions the build fails with an error `cannot find macro 'asm' in this scope.` Just needs a single-line fix and the error message is pretty helpful. I guess you're pinning to a particular version of nightly in your build infrastructure, but haven't done that in the build files here?
Author

The objcopy step also failed for me arm-none-eabi-objcopy -O binary thermostat.elf thermostat.bin. The build outputs didn't have a thermostat.elf just thermostat and it wasn't in the file place that objcopy was looking for it. (FWIW the cargo-objcopy step with Booster seemed to work nicely for that project).

The objcopy step also failed for me `arm-none-eabi-objcopy -O binary thermostat.elf thermostat.bin`. The build outputs didn't have a `thermostat.elf` just `thermostat` and it wasn't in the file place that objcopy was looking for it. (FWIW the `cargo-objcopy` step with Booster seemed to work nicely for that project).
Owner

I guess you're pinning to a particular version of nightly in your build infrastructure

The instruction in README is actually "see the mcu folder of nix-scripts" i.e. follow what Hydra does. I suppose your issue is with shell.nix?

it wasn't in the file place that objcopy was looking for it.

What does that mean?

> I guess you're pinning to a particular version of nightly in your build infrastructure The instruction in README is actually "see the mcu folder of nix-scripts" i.e. follow what Hydra does. I suppose your issue is with shell.nix? > it wasn't in the file place that objcopy was looking for it. What does that mean?
Owner

If you're not using Nix: we're building with 2020-10-30 (https://git.m-labs.hk/M-Labs/nix-scripts/src/branch/master/mcu/channel-rust-nightly.toml). We could edit the Ubuntu commands in the README but they might go out of date again if nobody tests them regularly. Maybe they should be removed entirely then.

If you're not using Nix: we're building with 2020-10-30 (https://git.m-labs.hk/M-Labs/nix-scripts/src/branch/master/mcu/channel-rust-nightly.toml). We could edit the Ubuntu commands in the README but they might go out of date again if nobody tests them regularly. Maybe they should be removed entirely then.
sb10q closed this issue 2022-01-05 08:09:26 +08:00
Author

The instruction in README is actually "see the mcu folder of nix-scripts" i.e. follow what Hydra does. I suppose your issue is with shell.nix?

I wasn't using nix at all.

Maybe the instructions were a bit ambiguous before, but the way I read it was there there was a section on building with nix (which, as you say, pretty much said "see the nix scripts folder") and a section on building with linux that did not mention nix. I was following the latter instructions.

I see you've now removed the build instructions for non-nix builds entirely (just saying "figure it out from the nix scripts). IMHO it's a real shame not to provide basic non-nix instructions for such a simple project.

Can't we just pin cargo to a version of nightly so that all builds use the same rust version regardless of whether or not we're using nix? Why does this have to be done in nix?

> The instruction in README is actually "see the mcu folder of nix-scripts" i.e. follow what Hydra does. I suppose your issue is with shell.nix? I wasn't using nix at all. Maybe the instructions were a bit ambiguous before, but the way I read it was there there was a section on building with nix (which, as you say, pretty much said "see the nix scripts folder") and a section on building with linux that did not mention nix. I was following the latter instructions. I see you've now removed the build instructions for non-nix builds entirely (just saying "figure it out from the nix scripts). IMHO it's a real shame not to provide basic non-nix instructions for such a simple project. Can't we just pin cargo to a version of nightly so that all builds use the same rust version regardless of whether or not we're using nix? Why does this have to be done in nix?
Owner

just saying "figure it out from the nix scripts

It doesn't actually say that. It tells you to use rustup and find the nightly version to use from a specific file in nix-scripts.

Then yes it's up to you to figure out how to set up rustup, and use it according to its latest user guide to install the specified Rust toolchain version.

We rarely use rustup at m-labs and nobody is going to maintain the rustup instructions, so what I wrote sounds like a good compromise.

> just saying "figure it out from the nix scripts It doesn't actually say that. It tells you to use rustup and find the nightly version to use from a specific file in nix-scripts. Then yes it's up to you to figure out how to set up rustup, and use it according to its latest user guide to install the specified Rust toolchain version. We rarely use rustup at m-labs and nobody is going to maintain the rustup instructions, so what I wrote sounds like a good compromise.
Owner

Can't we just pin cargo

The pinning is done by the Rust channel manifest file (which isn't specific to Nix) which I committed in nix-scripts, and goes further than cargo.

> Can't we just pin cargo The pinning is done by the Rust channel manifest file (which isn't specific to Nix) which I committed in nix-scripts, and goes further than cargo.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/thermostat#61
No description provided.