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

Bazel – Correct, reproducible, fast builds for everyone

bazel.io

Post reply on HN
Print view View original

171–180 of 185 posts

Re: Bazel – Correct, reproducible, fast builds for everyone

#171

Post by w4tson »

cromwellian wrote: post #147
w4tson wrote: post #140

It's another impressive feat from Google and reading the comments I've kind of established that 1. Binaries are checked in to source 2. It's more structured than Gradle 3. It's for very large code bases 5. It's nix only But... 1. We've already had the "chuck it in a lib directory" approach. The distributed approach maven/ivy etc seems to be working for the millions of developers out there who just have to get through…

I don't know about Bazel, but Blaze doesn't "check in binaries". Build artifacts are cached, but not "checked in". The problem with maven and gradle is that their build actions/plugins can have have unobservable side effects. This approach is more 'pure functional'. You have rules which take inputs, run actions, produce outputs and memoize them. If inputs don't change, then you use memoized outputs and don't run the…

Apologies for comment- I'd just gotten home from the pub was drunk :D

I look forward to trying it out. The ObjectiveC rules sound interesting especially given the state of XCode which is a laughable IDE.

Re: Bazel – Correct, reproducible, fast builds for everyone

#175

Post by woah »

nevir wrote: post #15
habosa wrote: post #4

Working at Google, Blaze is one of the technologies that amazes me most. Any engineer can build any Google product from source on any machine just by invoking a Blaze command. I may not want to build GMail from source (could take a while) but it's awesome to know that I can. I think this could be hugely useful to very large open source projects (like databases or operating systems) that may be intimidating for contri…

Well, that's also largely due to all the source (transitive dependencies) being present in one monolithic repo.

Yea what's up with that? Sounds like a pretty terrible practice to me. Is that something that c++ forces you to do?

Re: Bazel – Correct, reproducible, fast builds for everyone

#176

Post by Filligree »

krupan wrote: post #154
pnathan wrote: post #72

Earlier quoted context omitted.

If you have a centralized version control system such as Clearcase or SVN, it's not such a grief to have binaries in VCS, whereas its kind of a problem for git & co. Google has a legendarily awesome centralized version control system.

"legendarily awesome centralized version control system" I thought it was just perforce.

It started as Perforce. Then they built better wrappers around it, then they stopped using perforce commands at all, then they rewrote the wrappers without reference to Perforce at all.

So there's no longer any perforce.

Re: Bazel – Correct, reproducible, fast builds for everyone

#177

Post by thechao »

beagle3 wrote: post #168
thechao wrote: post #158

Earlier quoted context omitted.

> Do you have some kind of way to verify that your makefile dependencies conform to your source dependencies? Nope. I explicitly use a conservative approximation—this guarantees correctness, over speed. Building everything every time with a clean tree is where I begin; I start optimizing after that. > Is clang/gcc tracking sufficient for your use case? What about upgrading the compiler itself, does your makefile depe…

Thanks. > this guarantees correctness, over speed. Wouldn't "promotes" be a better word? what guarantee do you have? > Self-rewriting Makefiles (to consume the .d files), combined with the cleaning necessary for them, become a large technical debt—especially given the complexity of the Makefile needed to generate them. Modern CCen just aren't capable of this. Haven't needed it in a long time, but back when I did gene…

Maybe... 'prefer'. I'm more confident that a really conservative Makefile will build my code correctly.

My issue with -MD was not that it didn't provide precise (and correct!) dependencies; my issue was that the build system's most mysterious breakages are when modules (and dependencies) are changed. In that case, there are three situations:

1. Your .d files are out-of-date, and thus your build is broken;

2. You have to have a policy of "updating the .d files"; or,

3. Your makefile has to be .d savvy.

The last option is the one I see most often taken, but with rare success.

> it makes correctness guarantees that Make cannot (e.g., .o file replacement is atomic).

I wish Make wasn't so entrenched.

Re: Bazel – Correct, reproducible, fast builds for everyone

#178

Post by dpark »

woah wrote: post #175
nevir wrote: post #15

Earlier quoted context omitted.

Well, that's also largely due to all the source (transitive dependencies) being present in one monolithic repo.

Yea what's up with that? Sounds like a pretty terrible practice to me. Is that something that c++ forces you to do?

No, it's something that Perforce allows (because it scales sufficiently). It has nothing to do with C++.

You can impose order within the monolithic repo by partitioning projects into their own branches or directories and only pulling down the necessary pieces.

Whether this is better than a bunch of small repos is debateable.

Re: Bazel – Correct, reproducible, fast builds for everyone

#179

Post by nevir »

woah wrote: post #175
nevir wrote: post #15

Earlier quoted context omitted.

Well, that's also largely due to all the source (transitive dependencies) being present in one monolithic repo.

Yea what's up with that? Sounds like a pretty terrible practice to me. Is that something that c++ forces you to do?

Just philosophical. I'm honestly not sure which approach I like more after having done it both ways: highly isolated projects (open source world, at Amazon), and monolithic (at Google).

It all boils down to dependency management in the end.

---

For the monolithic world:

* You're always developing against the latest version of your dependencies (or very near it).

* This comes at the cost of a continuous, but minimal, maintenance burden as upstream folk make changes.

* * However, because things are monolithic, upstream projects can change _your_ code, as well. You can be confident that you know exactly who is affected by your API change.

* * Similarly, being able to make an API change and run the tests of _everyone that depends on you_ is a huge benefit.

* You have to be more diligent when testing things that go out to users, as your code is constantly evolving.

---

For the isolated world:

* You can develop without fear of interruptions; your dependencies are pinned to specific versions.

* You get to choose when to pay the cost of upgrading dependencies (but typically, the cost is pretty high, and risks introducing bugs).

* * Security patches can be particularly annoying to manage, though (if you let your dependencies drift too far from current)

* During deployment, you can be extremely confident about the bits that go out.

* You can get away with less rigorous infrastructure (and maintenance costs related to that)

Re: Bazel – Correct, reproducible, fast builds for everyone

#180

Post by nevir »

dpark wrote: post #178
woah wrote: post #175

Earlier quoted context omitted.

Yea what's up with that? Sounds like a pretty terrible practice to me. Is that something that c++ forces you to do?

No, it's something that Perforce allows (because it scales sufficiently). It has nothing to do with C++. You can impose order within the monolithic repo by partitioning projects into their own branches or directories and only pulling down the necessary pieces. Whether this is better than a bunch of small repos is debateable.

Perforce (the product) doesn't really scale sufficiently for the Googles/Amazons/Microsofts of the world, sadly.

I think they've all moved to custom forks/implementations due to the insane SPOF that Perforce servers are (and their hardware requirements). But up til that point, heck yeah!

Post reply on HN