151–160 of 257 posts
In practice, I spend under two minutes to click around and see if can 'get' it. What does it do especially well? What's the syntax look like? If you are brave, what doesn't work well?
No idea why this exists or why I would use it. Bad website. No cookie.
Earlier quoted context omitted.
Silo’d development isn’t a matter of tooling, it’s a matter of communication.
There's an interplay between them. Communication always has a cost; there are certainly things you can do to the constant factors, but in a 100-person engineering organization with 20 teams, it's fundamentally going to be much easier for an engineer on one team to write a build system (or pre-merge CI flow, or whatever) that meets the needs of their four teammates working on the same code than one that meets the need…
At the micro-level, tools help, no doubt about it. At an org level, communication helps (documentation is a form...). Even if using different tooling, concepts and strategies are the same. This isn't to take away from the argument that this tool the OP posted is pretty awesome.
If you want change, be the change. Evangelize the tool through your org, not just your team. If your org is silo'd, break those barriers down with a friendly lunch-n-learn or lightning talks session. We tout empathy for our customers, how about empathy for our coworkers too? Others may have the same pain...
Earlier quoted context omitted.
The JRE is 655.8M on my system.
And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download. However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds. But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing i…
[1] https://en.wikipedia.org/wiki/List_of_countries_by_Internet_...
I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?
1. Reproducible/Hermetic: your builds cannot, say, access the network during a step or produce changing binaries for the same input. This makes sure that once you've downloaded your deps locally everything builds correctly from then on.
2. Caching: Because everything is reproducible in bazel-likes everything is cachable. Dependencies, builds, and even tests! If you've worked with Makefiles you've likely run `make clean; make tests` or something similar. I've never needed to do `bazel clean` to make sure things were working right.
3. Visibility: you don't only control who can see what in your source code. Different dependencies can be marked as private/protected/public to control who can import them. This is a huge boon to large monorepos.
4. Everything is uniform: code generation, compilation, etc is all described in "rules" and "toolchains" and can "easily" expanded to other languages. The community manages a Rust and Golang rules set for bazel itself and they're better then the Google rule sets for Java (only "officially" supported rule set right now) in some areas.
So if you have a lot of code/internal libraries/code generation, what to write a LOT of unit tests and cache their results, and write code in multiple languages bazel is probably for you.
You can also use tools like BuildBuddy [0] to share a cache with your team and extract build performance metrics to identify areas you can improve performance in.
[0] - https://www.buildbuddy.io/ or https://github.com/buildbuddy-io/buildbuddy
Earlier quoted context omitted.
Makefiles operate at a low level of abstraction. The Makefile abstraction is "run this command when the output files don't exist or are older than the input files." You manually specify every tool to be run and all of its arguments. These tools operate at a higher level of abstraction. The BUILD file abstraction is something like "I am declaring a C library with these sources and headers." The build system then turns…
> The Makefile abstraction is "run this command when the output files don't exist or are older than the input files." You manually specify every tool to be run and all of its arguments. > The BUILD file abstraction is something like "I am declaring a C library with these sources and headers." This is wrong. Even ninja has generic rules. Here's an example of a minimal makefile: OBJ = src/a.o src/b.o src/c.o libfoo.so:…
Your example does not contradict what I wrote. You manually specified the tool to be run ($CC) and all of the arguments to that tool.
It's true that there is a level of indirection through the $CC variable, but you're still operating at the level of specifying a tool's command-line.
> There's no reason this shouldn't be possible with make; it just hasn't been implemented so.
Make is 44 years old. If it were an easy extension to the existing paradigm, there has been ample time to implement such an extension.
> Do bazel/buck/please actually do this? As far as I know tup is the only tool that actually verifies inputs/outputs of rules, and it needs FUSE to do so.
Bazel certainly has some amount of sandboxing, though I don't think it's quite as complete as what is available internally at Google with Blaze. I haven't used Buck or Please, so I can't speak for them.
> True, it's a bit of a footgun, but by no means difficult.
Well footguns aren't great. :) As just one example, any header that is conditionally included (behind an #ifdef) could cause this cache to be invalidated when CFLAGS change, but Make has no idea of this.
I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?
Make has a laundry list of problems: - Cannot handle multiple outputs for a single rule - Does not rebuild when flags change - Make rules may contain implicit dependencies - Slow for large codebases - Does not understand how to build for multiple platforms, sucks for cross-compiling - Recursive make sucks (job control does not work across recursive invocation boundaries) - You must create output directories yourself…
Title can possibly be modified to mention that this is a tool to build code.
> Please (please.build) 'build' kind of indicates that
Can somebody sell me this tool while comparing it to `make`, or Elixir's `mix`, or Rust's `cargo`?
Please is a lot more lightweight than Bazel, so it’s easier to get deployed and work with different projects. The new maintainer has been shaving off a lot of warts lately and it’s getting a lot better.
If the above doesn’t describe your situation, then a tool like please, pants, buck, or bazel is probably not for you. And that’s ok too.
"Please supports Linux, macOS and FreeBSD at the moment" Let me know when I can actually use this on any machine I have to work on, instead of going "fuck you, Windows users". Writing cross-platform build tooling isn't rocket science, it's a choice. And the choice made here is stupidly disappointing in near as makes no difference 2021.
Devs on Unix are by the far the worst when it comes to writing cross platform code. This is written in go! How isn't it cross platform?!
Earlier quoted context omitted.
Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it. With that being said I have put a good amount of work into the QuickStart. The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’…
As someone who has had to run and maintain build systems for several (sadly far too) large projects (5MLoc+), I want a product that sells me on how easy it is to create _correct_ builds, and how impossible it is to create incorrect ones. So much wasted time goes into diagnosis of incorrect results from incremental builds that most people who implement CI systems never use incremental builds, and always build from scr…