3 ms·

> A more radical extension to the former approach is to actually check everything in your version control system. Everything as in the source of every single to

by ilurk 11y ago

> A more radical extension to the former approach is to actually check everything in your version control system. Everything as in the source of every single tool. That’s how it’s working when you are “building the world” on BSD-like systems. That’s also how Google is doing it internally. To make absolutely sure that everything is checked-in, you can even use “sandboxing” mechanisms > Google recently started open-sourcing the tool they use internally to drive such large scale builds under the name Bazel. So despite its syntax that I personally find hard to read, it’s probably worth checking out. Can anyone comment on the differences between Bazel and Debian's reproducible builds? Is the "Google is doing it internally" the same as Bazel? (they are eating their dog food [1]) If it is then, does Bazel allow building from a reference VM or docker instead of building every tool and library from source? What I'd like to know is what is worth adopting if you're in a small company (not a AmaGooFaceTwi). [1] https://plus.google.com/+RipRowan/posts/eVeouesvaVX https://plus.google.com/+RipRowan/posts/eVeouesvaVX

walterbell 11y ago
This discussion of Bazel, by a Google Blaze user, identifies four issues for adoption of Bazel by OSS projects, http://julipedia.meroh.net/2015/04/on-bazel-and-open-source.html http://julipedia.meroh.net/2015/04/on-bazel-and-open-source.... 1. Cross-project dependency tracking 2. Software autoconfiguration 3. It's not only about the build 4. The Java blocker
- jschwartzi 11y ago
  What do you have to do to get Basel to "build" a target that its designers have never encountered? The biggest problem I have with modern build systems is that they invest a lot in building specific types of artifacts. For instance, you might be able to compile and link a C program in three or four lines. In exchange, they fail miserably to account for situations like statically linking raw binary data into an executable or facilitating the automation of a target image build. So it's usually easy to build a desktop application but not much else. How easy would it be to automate a complete Android image build in Bazel?

by ilurk 11y ago

walterbell 11y ago

This discussion of Bazel, by a Google Blaze user, identifies four issues for adoption of Bazel by OSS projects, http://julipedia.meroh.net/2015/04/on-bazel-and-open-source.html http://julipedia.meroh.net/2015/04/on-bazel-and-open-source.... 1. Cross-project dependency tracking 2. Software autoconfiguration 3. It's not only about the build 4. The Java blocker

jschwartzi 11y ago
What do you have to do to get Basel to "build" a target that its designers have never encountered? The biggest problem I have with modern build systems is that they invest a lot in building specific types of artifacts. For instance, you might be able to compile and link a C program in three or four lines. In exchange, they fail miserably to account for situations like statically linking raw binary data into an executable or facilitating the automation of a target image build. So it's usually easy to build a desktop application but not much else. How easy would it be to automate a complete Android image build in Bazel?