Sharlatan Hellseher <[email protected]> writes: > Any plan to have Bazel in main Guix git repository or it's not > compatibly license wise?
Bazel is in guix-science, with a bazel-build-system as well. It's compatible when looking at just the licenses, but there are a number of annoying wrinkles: - Bazel itself bundles lots of binaries (Java libraries); I have made no serious attempt at unbundling them. Packaging Java libraries gives me ulcers. - the bazel-build-system works in ways that are really quite mismatched with how Guix works. It performs a two-stage build: the first step is to run Bazel to download "sources" in a fixed output derivation; the second step (at a later time) is to unpack these hash-identified sources and run Bazel again without the download. - Bazel makes it *very* hard or even impossible to replace parts of the build dependencies with packages from Guix. I recently added python-ray to guix-science, which insists on using its own GNU Make (among many others). This means that the source blob is usually incredibly large. - Bazel does not care about whether something is source or binary. The bazel-build-system assumes that the first step is to download sources only. Bazel does not see it this way and is perfectly happy to fetch or build binaries at this stage. It has happened a number of times that the hash of the fixed output derivation changed after an update of seemingly unrelated libraries, because the fixed output wasn't fixed after all. I'd rather move Keras to guix-science than to contaminate Guix proper with the abomination that is the bazel-build-system (and its relative Bazel, which I will attempt not to call an abomination in public). -- Ricardo
