3 ms·

I migrated a mid-size polyglot project from Makefiles to Bazel and C++ was a large component of the project. Some obstacles: 1. Building with QT5 MOC & UI fil

I migrated a mid-size polyglot project from Makefiles to Bazel and C++ was a large component of the project. Some obstacles: 1. Building with QT5 MOC & UI files. There is a great library[0] for it but it has hardcoded paths to the QT binaries and header files assuming a system-wide installation. I had to patch the rule to point to our QT location. Then it worked fine. 2. There is no rule to build a fully static library[1]. Since we were shipping a static library to clients via our Makefile system, that was somewhat annoying. 3. We were using system links like `$PROJECT_ROOT/links/GCC/vX.Y.Z/ -> /opt/gcc/...` to point to all the build tools, but these didn't work in Bazel I think because it required absolute paths for any binaries it calls. We ended up putting them in a .bazelrc but we would need a different one for Windows and Linux. 4. Not good integration with IDEs 5. (edit) The Bazel toolchain system is confusing and I couldn't understand it after reading all its docs Ultimately we did not keep using Bazel because we were building Python binaries and py_binary was too slow on Windows. And we didn't have enough time to write a PyInstaller rule. [0]: https://github.com/justbuchanan/bazel_rules_qt https://github.com/justbuchanan/bazel_rules_qt [1]: https://github.com/bazelbuild/bazel/issues/1920 https://github.com/bazelbuild/bazel/issues/1920

klodolph 4y ago
Regarding #3, my approach to solve problems like this is to make a custom repository rule which creates the desired symlinks. The repository rule can invoke external programs or examine the environment as necessary to figure out how this should be created. Basically, you create a repository rule that symlinks your $PROJECT_ROOT/links/GCC/vX.Y.Z/ to $repo/... somewhere, and then generates a BUILD file for the repository. Writing your own repository rule is not especially difficult and they do have a lot of power not available to ordinary rules. This is the API that you can use from within repository rules--you can see that it lets you run arbitrary programs, create files and symlinks, download files, etc. https://bazel.build/rules/lib/repository_ctx https://bazel.build/rules/lib/repository_ctx
rfoo 4y ago
#2: To be fair it is reasonably easy to make a cc_static_library_binary-ish rule which merges all transitive .a-s (just generate an ar script and call archiver). But I have to admit that I spent non-trivial time on maintaining our "CROSSTOOL in skylark" (forgot the term) for 20+ target platforms before and it helped a lot on understanding the (still incomplete) C++ sandwich.

klodolph 4y ago

Regarding #3, my approach to solve problems like this is to make a custom repository rule which creates the desired symlinks. The repository rule can invoke external programs or examine the environment as necessary to figure out how this should be created. Basically, you create a repository rule that symlinks your $PROJECT_ROOT/links/GCC/vX.Y.Z/ to $repo/... somewhere, and then generates a BUILD file for the repository. Writing your own repository rule is not especially difficult and they do have a lot of power not available to ordinary rules. This is the API that you can use from within repository rules--you can see that it lets you run arbitrary programs, create files and symlinks, download files, etc. https://bazel.build/rules/lib/repository_ctx https://bazel.build/rules/lib/repository_ctx

rfoo 4y ago

#2: To be fair it is reasonably easy to make a cc_static_library_binary-ish rule which merges all transitive .a-s (just generate an ar script and call archiver). But I have to admit that I spent non-trivial time on maintaining our "CROSSTOOL in skylark" (forgot the term) for 20+ target platforms before and it helped a lot on understanding the (still incomplete) C++ sandwich.