If only our code search and code review systems were public too.
BTW, do you have blaze build for gwt? ant seems unwieldy for me.
Bazel – Correct, reproducible, fast builds for everyone
151–160 of 185 posts
Re: Bazel – Correct, reproducible, fast builds for everyone
#152Earlier quoted context omitted.
Those complaints mostly seem to be about the developer experience on Mac, which, yeah might suck. I use VS + vim, build on Windows, then copy over to Linux for deployment. The biggest issue is with complicated frameworks, like ASP.NET, since there could be all sorts of runtime things missing. Fortunately with MS's new open source kick, this should be a thing of the past relatively soon,
So, you just told me to buy a Windows machine. Kind of funny because our little subthread started because the Microsoft F# developer didn't want to be told to buy a Linux or Mac. The world we're all looking for is one where we'd all like to mix and match our software as much as possible, and not be told to buy a different computer.
Fair enough; I went off track just about running (executing) F# code.
Re: Bazel – Correct, reproducible, fast builds for everyone
#153Earlier quoted context omitted.
I didn't say they weren't. I imagine the project needs lots of help. Is there an ETA? Will the ports be kept in sync with the Windows versions so we don't need to wait years for updates? It's a lot of work.
> Is there an ETA? I think their goal was a year for everything under .Net to get ported but I don't know off hand. You can already use it via Mono if you wanted to play with it today. > Will the ports be kept in sync with the Windows versions so we don't need to wait years for updates? It's all being opened sourced. Every week Microsoft open sources more of their .Net platform and language tools. It will be compilab…
And every court case fights to close off other things.
Re: Bazel – Correct, reproducible, fast builds for everyone
#154What 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.
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.
Re: Bazel – Correct, reproducible, fast builds for everyone
#155Wohoo! This is awesome :)
Re: Bazel – Correct, reproducible, fast builds for everyone
#156Earlier quoted context omitted.
A huge +1 on this as well. I left Google a couple of years ago and we ended up building our own rpc around protos (Thrift just doesn't cut it), and our Make/maven based build has the standard problems with such things, so I'm really looking forward to using grpc and bazel in the near future. A huge thumbs up to Google!
Can you give a (very quick) pointer/explanation to what about Thrift didn't cut it for you?
It wasn't invented in Google and is therefore inferior. Google has a massive incentive to develop projects specific to their requirements and then open source and evangelize them to stomp out approaches not optimized for them.
Re: Bazel – Correct, reproducible, fast builds for everyone
#157Re: Bazel – Correct, reproducible, fast builds for everyone
#158I've been burned by so many build tools over the years. I've finally settled (for C/++/asm) on the combination of Make + ccache: I build a _very_ paranoid Makefile that recompiles everything if it feels like anything changes. For instance, every rule that compiles a C/++ file is invoked if _any_ header/inc/template file changes. I let ccache do the precise timestamp/check-sum based analysis. The result is that (for l…
> 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 depend on that? If so, how?
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. Perhap Doug Gregor's module system will land in C21/C++21, and we'll see some good, then.
> Have you considered tup[0]? Or djb-redo[1]?
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. (This is a consensus opinion at my shop; I, personally, enjoy tup.)
> Why do you care about ar determinism? Shouldn't it be ld determinism you are worried about?
Determinism let's me cache *.o/a/so/dylib/exe/whatnot without getting false-positives due to time-stamp changes and owner/group permissions in the obj/ar files (see ar(1)). ld is deterministic under all the CCen I use by setting the moral-equivalent of -frandom-seed.
Re: Bazel – Correct, reproducible, fast builds for everyone
#159Earlier quoted context omitted.
A huge +1 on this as well. I left Google a couple of years ago and we ended up building our own rpc around protos (Thrift just doesn't cut it), and our Make/maven based build has the standard problems with such things, so I'm really looking forward to using grpc and bazel in the near future. A huge thumbs up to Google!
Can you give a (very quick) pointer/explanation to what about Thrift didn't cut it for you?
The description language is oddly bulky and can't decide what order it's in.
The api to open a connection is, again, needlessly bulky: I make a socket, I wrap it in a buffer, I wrap it in a protocol, I create a client using it, then I connect? There's the same level of complexity offered in grpc, but it's offered through an options object with sane defaults.
There's no security protocol; or, if there is, nobody seems to use it. Is there an async call structure? If there is, nobody's ever heard of it. All the code I can find seems to be written at a preschool level. This may be due to working at a company that was an early adopter, or simply because the company is staffed by preschoolers.
Re: Bazel – Correct, reproducible, fast builds for everyone
#160Earlier quoted context omitted.
Can you give a (very quick) pointer/explanation to what about Thrift didn't cut it for you?
The description language is oddly bulky and can't decide what order it's in. The api to open a connection is, again, needlessly bulky: I make a socket, I wrap it in a buffer, I wrap it in a protocol, I create a client using it, then I connect? There's the same level of complexity offered in grpc, but it's offered through an options object with sane defaults. There's no security protocol; or, if there is, nobody seems…
As someone that used to work at Google, and currently works at Facebook, there's a lot of legacy API that you can mostly ignore. Async is there, but more or less just works, and uses C++11 lambdas quite nicely.
I think I preferred Google RPC, but it's not a huge difference to me.