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

101–110 of 180 posts

Re: Bazel Release 1.0

#101

Post by random3 »

the-rc wrote: post #95
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.

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

Re: Bazel Release 1.0

#102

Post by lhorie »

Quekid5 wrote: post #100
lhorie wrote: post #90

Earlier quoted context omitted.

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?

You would have 5 workspaces. How they work together is sort of up to you.

If you use `local_repository`, then you can link whatever's checked out from version control together. This can be dangerous since there's nothing that enforces what version of what works with what, but it's helpful for example, if you want to beta test a new version of a ruleset in a workspace that consumes it.

If you want to be strict about publishing artifacts and versioning, then `http_archive` is the way to go. You can choose your publishing schedule and other workspaces can independently manage which versions of the published artifacts they want to use.

`git_repository` is a middle ground if you don't want the hassle of publishing versioned artifacts, since it lets each workspace reference specific commit SHAs for the things they import.

Re: Bazel Release 1.0

#103

Post by evmar »

klodolph wrote: post #11
dickeytk wrote: post #3

Earlier quoted context omitted.

Isn’t Bazel based off another tool they use internally?

Yes. My guess is that over a long enough period of time, the internal build system will migrate to Bazel. But I don’t think it will happen soon. Large migrations are always a pain, but Bazel does make it easier (since you can isolate dependencies very well and migrate bottom-up). I don’t work there, but I have talked to Googlers working on build systems.

Bazel is just the open source name of the internal Google build system, it is the same codebase.

Re: Bazel Release 1.0

#104

Post by m0zg »

jonhohle wrote: post #47
klodolph wrote: post #39

Earlier quoted context omitted.

> The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplementations. My experience from before Bazel is that reimplementations were the way to go most times you had projects with multiple languages, because the alternatives lead you down dark paths—calling into a separate build system suffers from the same problems as recursive make. What excites me about 1.0 is t…

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.

Re: Bazel Release 1.0

#105

Post by renox »

weberc2 wrote: post #87
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)

> Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again. I simply don't have time to write a program in a slow, stringly-typed, ad hoc DSL just to build my actual program.

At work, we use cmake; i've never seen a technology with so little 'traction'; I know one guy who is good with cmake all the other (including me) avoid touching this thing as much as possible!

Sigh, I remember debugging a complex makefile generation issue (it took me 3 days, two guys before me failed) and it didn't make me hate the make tool, I just wished it had better tracing/debugging but cmake that's a different story..

Re: Bazel Release 1.0

#106

Post by m0zg »

mrighele wrote: post #77
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…

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

I don't work in Java, but just so you know, you can define Maven deps in your WORKSPACE file, and Bazel will automatically download and cache them (and their dependencies) much like Maven would. The rest of the build is trivial to set up.

Re: Bazel Release 1.0

#107

Post by habitue »

zapita wrote: post #83
rad_gruchalski wrote: post #70

Am I correct in thinking that Bazel is a fantastic fit for golang with modules?

In theory, yes. In practice... you will need to either a) force everyone in your team to never use native Go tools ever, or b) cobble together third-party tools to bridge the two worlds. Start with https://github.com/bazelbuild/bazel-gazelle and see how deep the rabbit hole goes. It's possible, but it's not trivial, and not nearly as smooth as using the Go tools in the first place. Unless you have a hair-on-fire prob…

Yeah, I think the heuristic should be "Am I forced to migrate to bazel to solve real problems my company is having?"

Vs.

"Can I migrate because bazel is the new thing"

Re: Bazel Release 1.0

#108

Post by m0zg »

etxm wrote: post #75
miles_matthias wrote: post #37

Woo hoo! I got to spend a few days with the Bazel team in the NYC office a few weeks ago and they were really excited about this announcement coming out soon. Congrats! One of my favorite uses of Bazel is in CI/CD. I built a demo which builds the applications, creates Docker images, and then applies a K8s manifest to a cluster. It's OSS now under the GCP handle: https://github.com/GoogleCloudPlatform/gke-bazel-demo H…

Does it work with VB6?

You jest, but you could totally write the rules for it to support VB6.

Re: Bazel Release 1.0

#109

Post by oweiler »

mrighele wrote: post #77
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…

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

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.

Re: Bazel Release 1.0

#110

Post by jcelerier »

weberc2 wrote: post #87
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)

> Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again. I simply don't have time to write a program in a slow, stringly-typed, ad hoc DSL just to build my actual program.

> It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again.

most projects are using CMake nowadays : https://www.jetbrains.com/research/devecosystem-2018/cpp/

Post reply on HN