161–170 of 185 posts
Earlier quoted context omitted.
Do you also use timestamps like sjavac or some other mechanism, like hashing?
Bazel uses checksums to determine if builds are up-to-date, but shortcuts the checksumming if metadata (timestamp, filesize) have not changed between builds.
Earlier quoted context omitted.
s/not running Windows/not running Windows or refusing to install a free VM/ 5 or 6 years ago I had to have Windows to run CAD software, but I found it easier to have a virtualbox install w/ Ubuntu in it for software development than trying to write code on Windows. The performance was good enough an the usability was pretty good. I imagine it has only gotten better since then.
One company I work with has a firewall of a certain brand. It only works with windows or a mac, you can't connect to it from a command line it needs some stupid app that you download and install just to make a VPN connection. Not having a unix specific build system work on windows seems to be pretty much the expected behaviour. As opposed to a firewall that runs linux internally requiring windows or OS/X to talk to i…
OpenConnect 'just worked', thankfully.
Earlier quoted context omitted.
One company I work with has a firewall of a certain brand. It only works with windows or a mac, you can't connect to it from a command line it needs some stupid app that you download and install just to make a VPN connection. Not having a unix specific build system work on windows seems to be pretty much the expected behaviour. As opposed to a firewall that runs linux internally requiring windows or OS/X to talk to i…
I struggled with Cisco AnyConnect's linux client until I eventually found the open-source OpenConnect replacement. The Cisco website even detected that I ran linux and offered the linux client for download, whereupon it dutifully pushed the Windows client... The crappy linux client I did have had to come from our cloud vendor. OpenConnect 'just worked', thankfully.
What is this lameness? https://github.com/google/bazel/tree/master/third_party - why not use gradle repos to download jars with known hashes? Sticking all those jars in the git repo is just... well, I expected better from Google.
Try not to be so rude. The FAQ is pretty clear about their reasons. It talks about tools, not other dependencies, but I'm sure the reasoning is the same: "Your project never works in isolation... To guarantee builds are reproducible even when we upgrade our workstations, we at Google check most of these tools into version control, including the toolchains and Bazel itself." It's a sensible policy and one I use myself…
Some reasons are the bloat, the possibility of "accidental" forks when a non-upstream version is compiled and checked-in binary-only, crufty old versions hanging around, and security problems. It adds extra work for downstream packagers having to pick it apart for distros.
Bundling gets particularly bloaty for git repos, since the history is always included in each clone. For perforce or SVN it doesn't matter so much as you only get the latest version of everything. In git each time there's a dependency update, it will pretty much add the size of the new jar to the .git directory. Over time it's going to grow huge. If at a later date the repository owner decides on a new policy where the third party files are not bundled, then even removing the directory from the current head doesn't shrink the repo size.
There are binaries in there for Mac, Linux and Windows (.exe file at least). You either need one or the other, not all at the same time.
This sort of thing is fine for proprietary software used in a controlled environment, but for open source it looks kludgy.
An alternative could be to have a "dependencies" repository that would be shallow-cloned as needed. At least that way the source code repo only would have source in it, not jars or executables. It'd ensure separation was enforced and you could still track requirements per version or change the policy later.
Earlier quoted context omitted.
> I build a _very_ paranoid Makefile that recompiles everything if it feels like anything changes. Do you have some kind of way to verify that your makefile dependencies conform to your source dependencies? Is clang/gcc tracking sufficient for your use case? What about upgrading the compiler itself, does your makefile depend on that? If so, how? Have you considered tup[0]? Or djb-redo[1]? Both seem infinitely better…
> 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…
> 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 generating one for me was all of running the compiler with "-MD" in the compile phase, and including it in the Makefile - no special "make depend" phase, no noticeable slowdown. What technical debt are you ref
> Yes. They are both don't provide significantly better correctness guarantees combined with sufficiently better performance to justify the cost to porting to older Unixen.
Interesting. It is my experience that redo (from apenwarr) is trivial to run and use anywhere there's Python and isn't Windows -- it's almost as fast as Make, and it makes correctness guarantees that Make cannot (e.g., .o file replacement is atomic).
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.
I had a bit of a read but I didn't find where it explains (code or doc) how it achieves reproducible builds. It seems like a stricter, huge make-like harness (in fact it reminds me of the mozilla firefox python build system a bit). It's not bad by any means, but it seems like to me it doesn't "magically" fix the "be reproducible" problem at all (which is what it seem to claim) Am I missing something?
It never explains any of this explicitly, but there are hints. [1], [2], [3].
[1] "Many rules also have additional attributes for rule-specific kinds of dependency, e.g. 'compiler'" -- http://bazel.io/docs/build-ref.html#types_of_dependencies
[2] http://bazel.io/docs/build-encyclopedia.html#cc_binary.hdrs_...
[3] "The build system runs tests in an isolated directory where only files listed as 'data' are available" -- http://bazel.io/docs/build-ref.html#data
Edit: A comment below seems to suggest that this is not the case: "Within Google we use a form of sandboxing to enforce that" (emphasis mine). -- https://news.ycombinator.com/item?id=9259147