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

91–100 of 180 posts

Re: Bazel Release 1.0

#91

Post by evmar »

boris wrote: post #69
klodolph wrote: post #50

Earlier quoted context omitted.

It would be interesting to see how build2 achieves these things (hermeticity, cross-building, shared caches). I can’t see anything in the linked documentation that mentions these problems at all.

It currently doesn't do fully hermetic configurations (as in, where it is impossible for any inputs to come outside of the project). Instead build2 does high-fidelity builds where it makes sure that if any of the inputs change (including options, environment, compiler itself, etc), the target gets rebuilt. See my reply to a sibling comment for some details. We do plan to add support for hermetic builds though it won'…

Does build2 handle the case where code has

#include "foo.h"

and then, after a successful build, you create a new file named "foo.h" in a directory earlier in the search path than the foo.h that was used in the previous compile?

Re: Bazel Release 1.0

#92

Post by andrewbinstock »

henryaj wrote: post #62
dgellow wrote: post #25

Earlier quoted context omitted.

Isn’t Bazel jre based? I don’t think that something like Qt will ever go for a build tool that requires the whole java runtime as a dependency. (Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else)

Please[0] is a Bazel-like build system written in Go. [0] http://please.build/

But, unlike Bazel, it doesn't run on Windows, which is a big limitation in enterprises.

Re: Bazel Release 1.0

#93

Post by ses1984 »

klodolph wrote: post #32
ses1984 wrote: post #19

Earlier quoted context omitted.

I want to try this with a monorepo codebase now but every time I try to get started I feel overwhelmed. I'm trying to sell my team on it, but none of us has experience with bazel. I'm trying to figure out how to do a small poc where we migrate one intermediate thing in the monorepo to bazel and try to prove out how it can take over everything.

I have personally done this. - You are going to screw things up a couple times. The documentation for Bazel is not always clear, but you can usually find examples or explanations of complicated stuff on forums somewhere. - Start with a leaf dependency, something in your codebase that doesn’t depend on anything else. Then work your way up. Just write a WORKSPACE + BUILD.bazel in your root, and then put a BUILD.bazel i…

I appreciate your help and was curious if you could field one more specific question:

What if I wanted to fork tensorflow and integrate my project into it, would I need the tensorflow fork as something like a git submodule in my main repo, or is there a way to tell bazel there's another repo somewhere else and where it fits into the graph?

Re: Bazel Release 1.0

#95

Post by the-rc »

random3 wrote: post #78

I wonder how / if Bazel will integrate wit Google Cloud Build. IMO that should be an end goal for a tool like Bazel. At a first glance, they are (highly) incompatible. 1. Bazel's statefulness is a core feature while GCB is stateless. 2. They both need to control things holistically to work (or you lose advantages otherwise). So in order to benefit from the two, it would likely require GCB to work with Bazel natively…

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

Re: Bazel Release 1.0

#96

Post by gen220 »

kylecordes wrote: post #59
ufo wrote: post #18

Earlier quoted context omitted.

In the topic of classifying build systems, there was a really interesting paper about that published at ICFP last year https://blogs.ncl.ac.uk/andreymokhov/build-systems-a-la-cart... They classify it based on how the build system detects what needs to be rebuilt and how the build system chooses the order things should be built in

I'd like to get a good grasp of the differences between Bazel and Buck. I've used the Bazel but not Buck - most descriptions of Buck describe it as being pretty similar to Bazel. (Also, that's a very interesting paper, will read in depth.)

From a historical perspective:

Bazel is the open sourced version of Blaze, google's internal build system. Buck is Facebook's open source version of their own implementation of a Blaze-like system. Pants was built as an open source implementation of Buck, before Buck was open sourced.

From a bird's eye view, knowing this history of their creators, I would guess that Bazel is more complicated internally, its API has a wider surface area, and ships with many optimizations included for the use case of building extremely large artifacts with many, many dependencies.

Someone who's more familiar with both, feel free to add details or correct my over generalizations! I've used Pants professionally and tried setting up Bazel for personal projects, but found it was too complicated for my needs.

Re: Bazel Release 1.0

#98

Post by Quekid5 »

andrewbinstock wrote: post #92
henryaj wrote: post #62

Earlier quoted context omitted.

Please[0] is a Bazel-like build system written in Go. [0] http://please.build/

But, unlike Bazel, it doesn't run on Windows, which is a big limitation in enterprises.

That, and it doesn't actually support the multitude of weird things that Bazel does.

Re: Bazel Release 1.0

#99

Post by alexeagle »

klodolph wrote: post #28
neves wrote: post #20

My company uses Java and Javascript, our build system is Maven. It starts the npm/yarn build process. We have hundreds of projects in it. I don't like the tooks, but would it be worth the trouble to change to Bazel?

Bazel has good support for both languages. My personal experience is with the JavaScript + Rollup (or TypeScript + Rollup) rules for Bazel. There are rules for Bazel + Yarn integration and although I use them, I’m not really qualified to give an opinion. With the TypeScript projects I work on, you have an ordinary yarn.lock and some extra Bazel rules in WORKSPACE to install the packages, and then you use some Bazel r…

I just posted about recent changes we made in the Bazel JavaScript layer. It's easier to migrate now that you can continue running whatever tools with the same config as Maven is doing. For example, if the `ts_library` rule doesn't work for you, it's possible to just use `tsc` (with the caveat as you point out, it will be slower) https://dev.to/jakeherringbone/layering-in-bazel-for-web-389...

That, combined with Maven->Bazel being a common migration path for Java project, should mean that your costs to change are incremental.

Another benefit for large projects is test execution time. If you can parallelize all your testing on a farm of machines you can bring your CI time down by an order of magnitude.

Re: Bazel Release 1.0

#100

Post by Quekid5 »

lhorie wrote: post #90
Quekid5 wrote: post #89

What about non-monorepos? At my company we have quite a few large-ish projects (consisting of ~5 published artifacts, LoC doesn't matter for my question, but maybe 100k per project?), but the problem is that we want different organizations to have access to different subsets of our projects... so we don't have a mono-repo? It it possible to do some sort of conglomeration where we could bazel-all-the-things and still…

You could import each thing as `http_archive`s or `git_repository` or `local_repository`s and use visibility to manage what projects are allowed to use what

Just trying to understand... so we would have ~5 (going by my original example figure) Bazel builds and then use "imports of published things" to have projects that depend on each other work?
Post reply on HN