5 ms·

I'm not a fan of Bazel either. Luckily, this doesn't require Bazel. Their guide [1] explains how to build using regular make for RPi. [1]: https://www.tensorfl

I'm not a fan of Bazel either. Luckily, this doesn't require Bazel. Their guide [1] explains how to build using regular make for RPi. [1]: https://www.tensorflow.org/lite/rpi https://www.tensorflow.org/lite/rpi

m0zg 8y ago
I'm a big fan of Bazel (or its Google internal counterpart, Blaze). Such a big fan, in fact, that I even use it for Python projects, and package outputs into Google PAR: https://github.com/google/subpar https://github.com/google/subpar. As long as you stick with the official 4 Google languages (C++, Java, Python, Go) it doesn't get any better IMO, as far as build systems are concerned. I do wish it didn't require Java though.
- lovelearning 8y ago
  I have a bad impression of Bazel for multiple reasons. I wanted to build TF on the Pi but at the time I assumed it required Bazel. Bazel had no ARM version (my experience was in mid-2017). I had to first build Bazel from sources. Failed a few times because its heap settings were too low, required a lot more swap and storage than I expected, and got the Pi so hot that I had to quickly setup some cooling fans around. A successful build took ~1.5 hours on a RPi 2. Then the full TF build using Bazel took some 10-11 hours. Finally, Bazel's command-lines - ex: "bazel build --config=opt -k //tensorflow/tools/pip_package:build_pip_package" - felt very counterintuitive and not easy to remember. For the first two problems, I learnt it the hard way that a cross-compilation environment is better than building on-device. The last one I still have a problem with.
  - m0zg 8y ago
    Bazel makes it reasonably straightforward to set up crosstool (a cross-compilation toolchain). That's how it's supposed to be done, whoever ported TFLite to Pi just probably neglected to provide a crosstool for it. It's a much better dev experience if you have a crosstool. Rebuilds on changes are near instantaneous and fully incremental. Toolchain can be set up to only be downloaded as needed. A good PR idea for someone, if it's not already done?

m0zg 8y ago

I'm a big fan of Bazel (or its Google internal counterpart, Blaze). Such a big fan, in fact, that I even use it for Python projects, and package outputs into Google PAR: https://github.com/google/subpar https://github.com/google/subpar. As long as you stick with the official 4 Google languages (C++, Java, Python, Go) it doesn't get any better IMO, as far as build systems are concerned. I do wish it didn't require Java though.

lovelearning 8y ago
I have a bad impression of Bazel for multiple reasons. I wanted to build TF on the Pi but at the time I assumed it required Bazel. Bazel had no ARM version (my experience was in mid-2017). I had to first build Bazel from sources. Failed a few times because its heap settings were too low, required a lot more swap and storage than I expected, and got the Pi so hot that I had to quickly setup some cooling fans around. A successful build took ~1.5 hours on a RPi 2. Then the full TF build using Bazel took some 10-11 hours. Finally, Bazel's command-lines - ex: "bazel build --config=opt -k //tensorflow/tools/pip_package:build_pip_package" - felt very counterintuitive and not easy to remember. For the first two problems, I learnt it the hard way that a cross-compilation environment is better than building on-device. The last one I still have a problem with.
- m0zg 8y ago
  Bazel makes it reasonably straightforward to set up crosstool (a cross-compilation toolchain). That's how it's supposed to be done, whoever ported TFLite to Pi just probably neglected to provide a crosstool for it. It's a much better dev experience if you have a crosstool. Rebuilds on changes are near instantaneous and fully incremental. Toolchain can be set up to only be downloaded as needed. A good PR idea for someone, if it's not already done?