Evgeny's Notes

Adding toolchain binaries directly int the repository isn't actually a good idea: the repository is getting bigger and bigger. It takes a while to check it out even in a the case, you want just to take a look. So to add new toolchain, we will try to fetch it on "runtime", i.e. when we execute some bazel command. Today we will add a toolchain, that compiles aarch64 binaries from macOS. For fetching something from internet, bazel has an "http_archive" rule, we have already used it to fetch the rust_rules in the Part 1. We can fetch arbitrary archives with this rule, in our case the toolchain tarball. http_archive ( name = "aarch64-unknown-linux-musl" , sha256 = "4fbe95500c327828b437f380bb15851e9a8126cf95180fbf15b76b78e0322ae3" , urls = [ "https://github.com/messense/homebrew-macos-cross-toolchains/releases/download/v11.2.0-1/aarch64-unknown-linux-musl-x86_64-darwin.tar.gz" ], strip_prefix = "aarch64-unknown-linux-...

This is the third part of the series "Cross compilation of rust with bazel". Previous topics: What? Do I really need to configure C++ compiler to compile rust? Cross compilation of the rust code with bazel. Part 1. Compilation from macOS(Intel) to linux x86_64 finaly works. Cross compilation of the rust code with bazel. Part 2.   Next challenge is to cross-compile for armv7. This part we did together with my colleague Dima and we did it on linux. First thing, that we need is to add the target platform into our root BUILD.bazel platform ( name = "armv7-linux-musleabihf" , constraint_values = [ "@platforms//cpu:armv7" , "@platforms//os:linux" , ], ) And rust toolchain for the new target in the WORKSPACE file: rust_register_toolchains ( edition = "2021" , extra_target_triples = [ "x86_64-unknown-linux-musl" , "armv7-unknown-linux-musleabihf" , # NEW ], ) And as we remember from the part 1 ,...

This is the continuation of cross-compilation  topic that I've started in previous part What? Do I really need to configure C++ compiler to compile rust? Cross compilation of the rust code with bazel. Part 1. Since we need to add C++ cross-compilation toolchain, let's add the pure C++ project. This will help us to test the C++ toolchain separately I've added a typical C++ hello world impliemntaion and a BUILD file for it: cc_binary ( name = "hello-world" , srcs = [ "main.cpp" ], ) And our goal is to make it compilable for linux by command: bazel build //cpp/hello_world:hello-world --platforms=//:x86_64-linux --incompatible_enable_cc_toolchain_resolution If we just try it, we get and error,  (23:01:17) ERROR: /private/var/tmp/_bazel_evgenypetrov/e83d964deb47c21842622d1b7ffa55fc/external/bazel_tools/tools/cpp/BUILD:58:19: in cc_toolchain_alias rule @baze l_tools//tools/cpp:current_cc_toolchain: Unable to find a CC toolchain using toolchain resolution. ...

We deploy to several different platforms. x86_64 - Linux containers armv7 - linux boards  arm64 - linux boards mipsel - linux boards  For the development we use x86_64 and arm64 mac OS and x86_64 linux laptops. Obviously we need to cross-compile our software. Till now we are mostly doing it using `cross-rs` for cross-compiling rust. It works well, only problem is that it is not part of our bazel build, and therefore it is running only when needed, takes more time etc. In the next weeks I plan to support cross-compilation for our target platforms using bazel. Cross-compilation support matrix Host OS x86_64 linux armv7 linux mips linux x86_64 mac os x86_64 linux ✅ native x86_64 mac OS 🔄 in progress ✅ native arm64 mac OS   I'll be updating demo-repository as I progress. In this post I'll start from some basic experiments/configurations. What? Do...

Sometimes previous experience really matters.   I have a backend-engineering background and at  @qwello.charge  I'm involved in embedded development. This time I'm writing an application that stores data in the chip memory. I've experienced an issue that I couldn't explain for a few days: after hardware reset, everything works. But works only once.   The second attempt yields garbage in the memory I try to write to. Debugging doesn't help, all the data I sent to write is correct. The "write operations" seem to be successful. But data in memory is not what I just sent.   I've lost a few days trying to figure out, what's wrong. My experience pushed me to check the indexes and addresses several times. "Computer is dumb, it just does what you tell it" right? The issue was the way the flash memory works. During writing, it writes only "0"s. To write "1"s you need to erase the memory. In this case, the consequent write will ...

In my opinion tracking of coverage, percent gives a false impression of "well tested" code. Test coverage is defined as a percentage of lines executed during the test. If test coverage becomes the main metric of testing it requires a lot of work. When high coverage is achieved, it gives the false impression of a well-tested code. See my artificial example on the image. Even "being well tested" is not a goal of software engineering. The tests are there to give developers and stakeholders confidence in the stability of software in real circumstances. And therefore focus during testing should be focused on the coverage of typical situations, and dangerous situations. The coverage calculation can still be valuable in such cases when developers understand that the project is not tested well.  In this case, coverage shows which module should be tested first. And looking at coverage precisely developer can see that branch, which handles an important use case is not covere...