shaka-player-embedded
shaka-player-embedded copied to clipboard
[Discussion] Consider switching to Bazel
We currently use GN to build the project. This is Chrome's build system and has a very expressive and versatile syntax. Bazel is built to be a more general-purpose build system. GN has a bunch of problems with it, mainly since it is built around Chrome and isn't built to be a general-purpose build system.
Some problems with GN:
- Requires downloading 350MB of code and it must be at specific paths, polluting the root folder.
- Requires downloading depot_tools, even though we don't use much from it.
- Doesn't give a huge control over flags or other settings.
- Creating custom toolchains for partners will be difficult.
- There is no documentation about what flags are being set and partners will have a difficult time changing them (if they can at all).
- We need to import Chrome's version of test tools, whereas we could use just use googletest directly with Bazel.
- Probably no one outside Chrome is using GN in their project, which makes integrating our source builds difficult.
Advantages of GN:
- Works very well "out of the box". Adds useful flags and tools.
- Battle tested flags and build settings (Bazel doesn't add much for flags, which can be an advantage).
Problems with Bazel:
- We would need to create build files for V8 and building with Bazel isn't officially supported by V8.
- BUILD files are hermetic, so it can't read external files. This will make FFmpeg builds harder. (it will probably require generating the BUILD file when ./configure is run)
- The syntax is harder to read when there are complex conditionals.
- It is difficult to create build "options" (e.g. --disable-hardware-decode).
- I haven't tried building/testing things for iOS, but it is supported.
Advantages of Bazel:
- Can handle downloading third-party code so it isn't even a submodule.
- iOS build rules are actually documented (https://docs.bazel.build/versions/master/be/objective-c.html)
- If we want to use abseil (https://abseil.io/, A Google utility library) we can just import it with 4 lines and a deps entry.
- Including googletest is similarly easy.
- The extensions are (basically) Python, which will make it easier to understand.
- Forces us to be more hermetic with packages.
- Will make it easier to document third-party dependencies and it may be possible to more easily automate getting LICENSE's.
Common problems with both:
- We need to write our own build files for most third-party projects.
- Requires partners to use this to build their project or risk binary incompatibilities.
- We still need an explicit ./configure step to setup third-party dependencies.
Estimated work: We would need to rewrite all our build files to use Bazel syntax instead, which may involve converting some of our build script helpers. Writing V8 build files may be fairly difficult, depending on how many options we want. It may be as easy as "build every file". The good news is the two build systems can live side-by-side, so we can keep old builds working while we slowly migrate to Bazel if we want.
Personal opinion: I like GN's syntax much more than Bazel's; it is much easier to understand at a glance. But it is built to be used with Chrom's build files and doesn't give us much flexibility. My concern is also that they won't fix bugs that only affect is: for example, we have problems with using ios_framework_bundle, but they might not fix it because GN isn't built to be used outside Chrome.
Bazel is also much more likely to be used by partners than GN and Bazel's toolchain work is much easier to understand. It also gives us more control over flags and options, which can be good or bad (but probably good for partners).
Suggested next steps: I would suggest we try converting our build files to see how much work it would be to get an iOS build working. Then we can see how different the syntax is and what it gains us. Then we see if it would be too much work to create and maintain V8 build files (remember that Linux isn't really a target platform).
Hello, since this is a blocking issue for the apple tv support, do you please have any ETA as to when you could switch to Bazel? Apple TV would be handy to have 👍
Thank you Jakub
Unfortunately, other projects are higher priority right now, so I'm unable to work on this for a while. This will probably be the next major thing I work on, but it may be a few months.
@TheModMaker can you explain where you get the 350MB of code required for GN? That seems unrealistic by a HUGE amount.
My guess is I included depot_tools
in that estimate; which for me, is 906MB as of now. It would be much smaller with no git history and not having a bunch of old versions of binaries in that folder. With just the code in the repo, there is ~53MB of code in the repo needed for GN (base
, build
, buildtools
, testing
, and tools
).