Add support for mac-osx and windows

[nathaniel-brough]

As it currently stands only linux is fully supported. The following functionality needs to be added and tested for complete cross platform support. OSX:

• [x] Openocd repository fetch
• [x] Openocd runs as expected when integrating with debugger hardware
• [x] Add to CI

Windows:

• [x] Openocd repository fetch
• [ ] Openocd runs as expected when integrating with debugger hardware
• [x] Compiler support
• [x] Add to CI

[nathaniel-brough]

@bradegler if you have time to test the openocd rules on osx, then that would be fantastic. If you just plug in your nrf52 board add the following two files into an empty directory. Then run bazel run //:debug_server. This will run the openocd server. If it doesn't immediately exit then that should be fine. This is just on the mac_osx branch, if you want to look over the code.

WORKSPACE

load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")

git_repository(
    name = "bazel_embedded",
    commit = "27ad3020ee4d880408c89896232e9ac327410f0c",
    remote = "https://github.com/silvergasp/bazel-embedded.git",
    shallow_since = "1585022166 +0800",
)

load("@bazel_embedded//:bazel_embedded_deps.bzl", "bazel_embedded_deps")

bazel_embedded_deps()

load("@bazel_embedded//platforms:execution_platforms.bzl", "register_platforms")

register_platforms()

load(
    "@bazel_embedded//toolchains/compilers/gcc_arm_none_eabi:gcc_arm_none_repository.bzl",
    "gcc_arm_none_compiler",
)

gcc_arm_none_compiler()

load("@bazel_embedded//toolchains/gcc_arm_none_eabi:gcc_arm_none_toolchain.bzl", "register_gcc_arm_none_toolchain")

register_gcc_arm_none_toolchain()

load("@bazel_embedded//tools/openocd:openocd_repository.bzl", "openocd_deps")

openocd_deps()

BUILD

load("@bazel_embedded//tools/openocd:defs.bzl", "openocd_debug_server")

openocd_debug_server(
    name = "debug_server",
    device_configs = [
        "board/nordic_nrf52_dk.cfg",
    ],
)

[bradegler]

Sorry for the delay. It appears to be working correctly on mac

INFO: Build completed successfully, 4 total actions
INFO: Build completed successfully, 4 total actions
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-12:31)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter speed' not 'adapter_khz'
adapter speed: 3300 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link OB-SAM3U128 V3 compiled Jan 21 2020 17:31:29
Info : Hardware version: 3.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections

[nathaniel-brough]

No problems at all. Thank heaps for your help!!

[paul-demo]

I found that the tools downloaded from commit d3cbe4eff9a63d3dee63067d61096d681daca33b are not compatible with my x86 OSX machine. Specifically, it looks like an assembler/loader compatibility issue I vaguely recall seeing for linux vs OSX binaries. The error message is "cannot execute binary file".

external/bazel_embedded/toolchains/gcc_arm_none_eabi/gcc_wrappers/gcc: line 27: external/com_gcc_arm_none_eabi_compiler/bin/arm-none-eabi-gcc: cannot execute binary file

Is there a way to use a system installed arm-none-eabi-* toolchain? Or, is it possible to download from ARM directly rather than some windows.net domain?

I'm not really sure why this was changed since the original URL is more similar to what you get if you installed the tools using homebrew: https://github.com/ARMmbed/homebrew-formulae/blob/master/arm-none-eabi-gcc.rb or https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/gcc-arm-embedded.rb

[paul-demo]

Actually, if I download the files from that link manually, they do run on OSX. The .bzl file which chooses the OS in this project is picking the URL for Linux when it should be picking the URL for OSX. When I expunge and build, then for the first build I can see it is downloading the Linux version of the tools:

 Fetching ...mpiler; Extracting /private/.../external/com_gcc\
_arm_none_eabi_compiler/.../gcc-arm-none-eabi-9-2019-q4-major-x86_64-linux.tar.bz2

If I go run an example in bazel-embedded, it does pull the mac version. So something to do with the WORKSPACE instructions you have included to use bazel-embedded in an outside project is making "mac" not be in the actual repository_ctx.os.name.

Is it possible that repository_rule() doesn't inherit the repository_ctx/repository_os/name?

[nathaniel-brough]

Hmm, interesting. I don't actually own a mac, so I'd appreciate your help if you are up for helping me debug this. These builds are tested on mac in the CI, so I am unsure where the system is different from your system. Would you mind posting the output of bazel info?

[nathaniel-brough]

Is there a way to use a system installed arm-none-eabi-* toolchain? Or, is it possible to download from ARM directly rather than some windows.net domain?

I'm not really sure why this was changed since the original URL is more similar to what you get if you installed the tools using homebrew:

These are downloaded directly from ARM, the original URLs redirected to the windows.net domain when ARM switched their server hosting over to use windows. Bazel doesn't like being redirected to an entirely different domain so we switched over to just using the destination for the redirect. This is described in #40. If you use wget to download from the ARM URLs you will see it redirect to the windows.net domain.

[paul-demo]

>>> bazel info
DEBUG: Rule 'rules_cc' indicated that a canonical reproducible form can be obtained by modifying arguments shallow_since = "1583316607 -0800"
DEBUG: Repository rules_cc instantiated at:
  /<redacted_path>/WORKSPACE:12:20: in <toplevel>
  /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/external/bazel_embedded/bazel_embedded_deps.bzl:18:23: in bazel_embedded_deps
Repository rule git_repository defined at:
  /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/external/bazel_tools/tools/build_defs/repo/git.bzl:199:33: in <toplevel>
bazel-bin: /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/execroot/__main__/bazel-out/darwin-fastbuild/bin
bazel-genfiles: /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/execroot/__main__/bazel-out/darwin-fastbuild/bin
bazel-testlogs: /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/execroot/__main__/bazel-out/darwin-fastbuild/testlogs
character-encoding: file.encoding = ISO-8859-1, defaultCharset = ISO-8859-1
command_log: /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/command.log
committed-heap-size: 105MB
execution_root: /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/execroot/__main__
gc-count: 36
gc-time: 231ms
install_base: /var/tmp/<redacted_dir>/install/2502efd7503633eaedd3ac80c24d4e7a
java-home: /usr/local/Cellar/openjdk@11/11.0.12/libexec/openjdk.jdk/Contents/Home
java-runtime: OpenJDK Runtime Environment (build 11.0.12+0) by Homebrew
java-vm: OpenJDK 64-Bit Server VM (build 11.0.12+0, mixed mode) by Homebrew
max-heap-size: 4294MB
output_base: /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e
output_path: /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/execroot/__main__/bazel-out
package_path: %workspace%
release: release 4.2.1-homebrew
repository_cache: /var/tmp/<redacted_dir>/cache/repos/v1
server_log: /private/var/tmp/<redacted_dir>/5e0ebffe5c36461277ef0c6cd028f65e/java.log.pauls-mbp.swirhun.log.java.20211022-075815.80444
server_pid: 80444
used-heap-size: 59MB

[paul-demo]

My suspicion is that it is something to do with sandboxing on OSX

[paul-demo]

If I swap git_repository for local_repository, it pulls the correct build tools for OSX. I'm going to chalk this one up to bazel being a large and inscrutable project; and where/why it is messing up os name could be anywhere internally or in your .bzl files. So, I'll probably just mirror your bazel-embedded project and refer to it by a local_repository instead.

[bradegler]

I just tested the latest commit locally on my mac and didn't experience the issue you are seeing.

WORKSPACE

git_repository(
name = "bazel_embedded",
commit = "d3cbe4eff9a63d3dee63067d61096d681daca33b",
remote = "https://github.com/silvergasp/bazel-embedded.git",
)

bazel info

bazel-bin: /private/var/tmp/_bazel_<redacted>/ec3564ff0b6a3f36d8a7e9e730ff79cd/execroot/<redacted_dir>/bazel-out/darwin-fastbuild/bin
bazel-genfiles: /private/var/tmp/_bazel_<redacted>/ec3564ff0b6a3f36d8a7e9e730ff79cd/execroot/<redacted_dir>/bazel-out/darwin-fastbuild/bin
bazel-testlogs: /private/var/tmp/_bazel_<redacted>/ec3564ff0b6a3f36d8a7e9e730ff79cd/execroot/<redacted_dir>/bazel-out/darwin-fastbuild/testlogs
character-encoding: file.encoding = ISO-8859-1, defaultCharset = ISO-8859-1
command_log: /private/var/tmp/_bazel_<redacted>/ec3564ff0b6a3f36d8a7e9e730ff79cd/command.log
committed-heap-size: 322MB
execution_root: /private/var/tmp/_bazel_<redacted>/ec3564ff0b6a3f36d8a7e9e730ff79cd/execroot/<redacted_dir>
gc-count: 6
gc-time: 33ms
install_base: /var/tmp/_bazel_<redacted>/install/3f35760ddfd4a3f87218d5d376d7490e
java-home: /usr/local/Cellar/openjdk@11/11.0.12/libexec/openjdk.jdk/Contents/Home
java-runtime: OpenJDK Runtime Environment (build 11.0.12+0) by Homebrew
java-vm: OpenJDK 64-Bit Server VM (build 11.0.12+0, mixed mode) by Homebrew
max-heap-size: 4294MB
output_base: /private/var/tmp/_bazel_<redacted>/ec3564ff0b6a3f36d8a7e9e730ff79cd
output_path: /private/var/tmp/_bazel_<redacted>/ec3564ff0b6a3f36d8a7e9e730ff79cd/execroot/<redacted_dir>/bazel-out
package_path: %workspace%
release: release 4.2.1-homebrew
repository_cache: /var/tmp/_bazel_<redacted>/cache/repos/v1
server_log: /private/var/tmp/_bazel_<redacted>/ec3564ff0b6a3f36d8a7e9e730ff79cd/java.log.<redacted>.<redacted>.log.java.20211023-101407.59688
server_pid: 59688
used-heap-size: 79MB

I don't see any real differences between my bazel info and yours.

Could there be something else in your workspace that is polluting the repository_ctx.os.name?

[paul-demo]

Could there be something else in your workspace that is polluting the repository_ctx.os.name?

No, there is nothing else in my repo; the only thing in the WORKSPACE file is the example from bazel-embedded. It's very odd; it must be some difference in the sandbox or the OS.

[nathaniel-brough]

@paul-demo just as a sanity check, would you mind changing the commit to the latest commit in the repository as brad has mentioned. e.g.

git_repository(
    name = "bazel_embedded",
    commit = "d3cbe4eff9a63d3dee63067d61096d681daca33b",
    remote = "https://github.com/silvergasp/bazel-embedded.git",
)

I will update the readme to match this.

[nathaniel-brough]

Updated readme in #45

[paul-demo]

I will update the readme to match this.

That works! What's the difference? Were the instructions just referring to an older commit with broken os name detection? Thank you!

[nathaniel-brough]

Yeah, it's just the latest version, so all those minor bugs have been fixed. It's also why it worked when you were using local_repository, as you would have cloned the latest version and then pointed your workspace at that clone.

[nathaniel-brough]

Hey mate, I noticed you've posted the same question on a couple of issues. It's not a big deal but in general, I'd prefer that you;

1. Open a separate issue (if there are relevant open issues it's ok to add to the conversation there), OR
2. Ask questions under the discussion tab.
3. AND post your questions on a single discussion thread (Otherwise it just spams my notifications).

At the moment, windows support is lacking in some areas as it's not a platform that I use on a regular basis. Mac and Linux have much better support.

In terms of flashing to a microcontroller, check out the 'openocd' examples in the readme which cover the steps needed to flash to a microcontroller.