Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bazel Release 1.0

github.com

Post reply on HN
Print view View original

131–140 of 180 posts

Re: Bazel Release 1.0

#131

Post by aidenn0 »

wasyl wrote: post #123
aidenn0 wrote: post #63

If android switches to bazel now that bazel is 1.0 does that mean we can switch from a completely undocumented tool to a poorly documented tool?

> completely undocumented tool Gradle is far from "completely undocumented". Unless you mean Android Gradle Plugin, which surprisingly _is_ somewhat documented, although the docs are tough to accidentaly just stumble by

I was actually refering to Soong not Gradle. Soong has been replacing makefiles since android 7. Given that incremental builds are more of a "hopeful aspiration" rather than "something that actually works" in Android 6, I can't blame them too much for doing a major reworking.

Re: Bazel Release 1.0

#132

Post by weberc2 »

boris wrote: post #86
weberc2 wrote: post #81

Earlier quoted context omitted.

> I said it fixes the same problems as OP listed. The OP listed noted that hermeticity is required for fast builds, and that humans can't be relied upon to provide hermeticity as a property. How does build2 guarantee hermeticity or otherwise support fast builds without a clean room solution a la bazel?

The OP was vague on why exactly hermetic builds are required to achieve fast builds. The only concrete thing they mentioned is caching which doesn't require hermetic builds (in the strict sense, as in preventing any outside changes) provided you can detect changes accurately. To give a specific example, Bazel may prevent you from accidentally using a different version of the compiler while build2 will detect that you…

Caching depends on a correct model of the dependency tree. If a dependency isn't included in the model, then a non-hermetic tool will silently succeed, incorrectly while a hermetic tool will do the correct thing and fail the build. Keeping the model accurate is too hard for humans, so in practice, non-hermetic build tools can't cache correctly.

Re: Bazel Release 1.0

#133

Post by weberc2 »

thundergolfer wrote: post #129
weberc2 wrote: post #80

Earlier quoted context omitted.

> but the ecosystem around Bazel is quite bad at the moment I've noticed this as well. I'd love to use Bazel for our Python 3 project, but as far as I can tell, the advertised Python 3 support doesn't actually work. There are several issues filed for this, but apparently no progress since 2018. Some people reported workarounds, but none that I could reproduce. I believe the core is solid, but language support feels a…

Python support is very much alpha. We use rules_python and the “reported workarounds” include forking rules_python, reimplementing a Bazel pip package manager integration, and adding a few twists to your Python codebase to handle Bazel idiosyncrasies. It’s dozens of hours of work, and even then you quite easily can find yourself not enjoying Bazel’s caching features because of pip wheel being non-deterministic. It’s…

That makes sense. What doesn't make so much sense is that the documentation indicates that Python 3 is supported, but everything I've tried and everyone I've spoken to have indicated that it's just broken. In any case, I hope I can use it eventually.

Any idea if deterministic wheels is on the Python project's radar?

EDIT: Quick Google search answered my question--the first result is an issue you filed here: https://github.com/pypa/pip/issues/6505

Re: Bazel Release 1.0

#134

Post by aidenn0 »

m0zg wrote: post #104
jonhohle wrote: post #47

Earlier quoted context omitted.

Amazon’s build system handled this gracefully. Native build tool chains were always used, but wrapped in a relatively thin facade. As long as the buildtool could respond to a `release` target and put artifacts in a well known location it didn’t matter what the underlying implementation was. The biggest drawback that I could see was all dependencies and tool chain needed to be modeled, but once they were, incremental…

Can it do "bulletproof", repeatable incremental builds? I'm asking because I don't see how it would be able to, unless the toolchain is wired into your build system _at least_ as deeply as it is in Bazel.

Slightly OT, but Tup[1] handles this by sanitizing the environment and building in a FUSE filesystem to track reads and writes. It's bulletproof except for system header files (or more properly anything outside the root of your build, which usually is just system header files).

Nix[2] accomplishes bulletproof repeatable builds by sandboxing everything, but I don't believe incremental builds are a design goal (though if you modularize everything into different nix expressions you will in fact get annoyingly hard to use bulletproof incremental builds).

1: http://gittup.org/tup/

2: https://nixos.org/nix/

Re: Bazel Release 1.0

#135

Post by orbz »

random3 wrote: post #101
the-rc wrote: post #95

Earlier quoted context omitted.

There's a hosted Bazel in an early access preview. Tensorflow uses it.

Thank you! Would love to try that. How to access pre-release?

Just use it in your cloudbuild.yaml file: https://github.com/GoogleCloudPlatform/cloud-builders/tree/m...

Re: Bazel Release 1.0

#136

Post by weberc2 »

adev_ wrote: post #68
ihnorton wrote: post #22

I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel, but that's probably strongly conditioned on the quality of Windows support. Qt Co. have indicated that CMake is the most likely replacement for qmake in Qt 6, which would be a lateral change at best. Is anyone using Bazel to ship cross-platform GUI applications?

> I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel By the sake of God no. The last thing I need to compile Qt is a gigantic framework requiring the JVM. Plus the fact Bazel has so many side effect that that even quantum physics experiments looks more reproducible: Just try to compile tensorflow and enjoy the fun. Stick to CMake, thanks.

I get not wanting a JVM (although all else equal I’ll take the JVM dependency any day over CMake), but how is CMake _more_ reproducible than Bazel? The latter builds in a clean room, Make does not.

Re: Bazel Release 1.0

#137

Post by cromwellian »

adev_ wrote: post #121

I am going to be hated and downvoted for that but let's go... Bazel, like Bucks and other, try to bring on table a build system / deployment system that is multi-language, multi-platform and developer oriented. A holy Graal that many developer ( like me ) looked for decade and that many (large) organizations more or less tried to do one day (and most failed) It is a good idea. It is a required tool to improve product…

1) bazel can be built with a self contained bundled paired down jvm, and possibly an executable using GraalVM but I don’t know anyone who tried that yet.

2) bazel can do offline compiles, and is actually built to run in sandboxes

3) bazel can act as a build system only and delegate to externa package managers

Look at rules_nodejs for example and the managed_directories + yarn_install/npm_install rule

4) depend on already installed stuff. Toolchains already provide a way to do this, and the android_sdk_repository rule literally requires preinstallation.

Seems to me your making a lot of claims about bazel without having used it.

Re: Bazel Release 1.0

#138

Post by grandmczeb »

hsivonen wrote: post #112

How’s Bazel documentation these days for people who haven’t worked at Google? In April 2018, I tried to do a quick port of a tiny gsl::span-using toy app to absl::span, but I gave up, because Abseil wanted me to build my app using Bazel and Bazel docs seemed to assume that I already have some context that Googlers would have but I hadn’t. (I emphasize that this was a _quick_ attempt at a toy program and not about mak…

This is a legitimate criticism I hear even from new Google employees; Bazel's documentation is pretty hard to read unless you already know a lot of its core concepts, unfortunately.

Re: Bazel Release 1.0

#139

Post by dimator »

c4urself wrote: post #49
habitue wrote: post #35

Bazel may be 1.0 and the internal abstractions of dag solving etc are rock solid from years of use inside Google, but the ecosystem around Bazel is quite bad at the moment. They've been breaking backwards compatibility constantly, so rules authors have struggled to keep up (hopefully done now that it's 1.0). The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplem…

Agree. I've been dealing with Python rules for Bazel at work and the default implementation of re-downloading everything with pip became a real pain real fast. Decided to generate the third party py_library with a separate tool instead and much happier for it. As an aside for those looking to start with Bazel, it's worth checking out the BazelBuild Slack -- https://slack.bazel.build/

just curious: is that separate tool open source?

Re: Bazel Release 1.0

#140

Post by dikei »

swsieber wrote: post #115
oweiler wrote: post #109

Earlier quoted context omitted.

I think for Java projects Bazel is a very bad choice. Last time I've checked it was not even able to resolve dependencies transitively. And I doubt that it's faster than recent versions of Gradle.

I very much doubt that it's faster than Gradle, but Gradle does do quite a bit more than Gradle.

Bazel incremental build is much much faster than Gradle, if you follow the one-package-per-build rule.
Post reply on HN