221–230 of 257 posts
Earlier quoted context omitted.
Hm, I guess my point was that it still needs the JVM, it just uses the bundled version. I guess that wasn’t clear.
Yes, but the bundled JRE is slimmed down, to the point where, last I checked, the bazel standalone binary is ~50Mb.
"slimmed down"
lol.
Earlier quoted context omitted.
Incremental builds with the said tools (Please, Bazel) should be a non-issue due to emphasis on hermetic build from these tools.
Unfortunately, reality is messier than this. For example, Please currently has escape hatches that can be used that nullify these guarantees. What I have found is that if such a mechanism exists it will eventually be abused. My perspective here is specifically from that of a maintainer of large builds where the code base is always under active development. Murphy's law becomes your enemy at scale. This is not a criti…
Earlier quoted context omitted.
So what language do you build with it? And why was it better than the traditional build system of that language?
Plz is great for c++, and has a better workflow (IMO) vs (e.g) Cmake. The skylark-like syntax is easier to reason through than cmake generative expressions. Also the use of “plz run” vs “cmake -g; make; run”
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’…
This makes me sad. You hopefully have tried out many other build systems by now, been frusted with all of them, and only then made your own. And with all that experience with the status quo, marketing should be easy. If you haven't done that, this project is a net- negative on the world, because the proliferation of build systems exacerbates Conway's law and balkanizes our software commons. NIH in FOSS is not free.
I’m sorry, what?!
Do you realize the “sell something to people” industry has been at least as big as the tech industry for many decades and is the one growing faster and faster?
Also marketing has historically been a problem for people who make stuff.
Also, better have the Balkans of software than the USSR of mega corps.
Earlier quoted context omitted.
What was/is the motivation for this build system that an existing one doesn't satisfy?
We wanted something like Blaze (Google's system); at the time we were using Buck which didn't satisfy us (e.g. only one output per genrule, no directories; and it was more or less impossible to write first-class support for a new language without modifying the core system). Subsequently Bazel got released but we still find that a bit lacking in some areas; e.g. the CLI, the JVM reliance and some of Starlark (e.g. it…
People interested in type annotations can check this discussion: https://github.com/bazelbuild/starlark/issues/106
For most purposes, Bazel dependency on Java is an implementation detail (users don't need to install a JVM), although you might notice it if you need to bootstrap Bazel.
(I co-designed Starlark and I used to work on Bazel)
Earlier quoted context omitted.
I don’t about these new build tools, but I’ve usually found ninja to be faster than make in most situations at least. Also curious to know, is there no work done in the realm of developer productivity inside the FPGA world?
No unfortunately. The FPGA "build" realm is mostly a clusterfuck of proprietary tooling. It all has poor to nonexistent integration with, well, anything else. There are some things that are okay for simulation like Cocotb, but for actually building hardware FPGA designs, you are locked into the vendor's tools. The only exception is if you use a small, slow, and outdated FPGA, not suitable for large designs used in in…
I've only looked at modern tools briefly but everytime I come away realising we'd have to re-write everything. There is no out-of-the-box support for our tools/language and it would be a lot of work to learn someone else's DSL, re-implement everything and then potentially discover a load of ways it's broken for our workflow. Personally I think it'd be worth it in the long run but it's a really hard sell.
Earlier quoted context omitted.
I also was trying to figure out why I would use this over Bazel. Then I remember reading a story yesterday about how ex-googlers miss their tooling when they leave. Their CTO is an ex-googler, so maybe this is the reason.
But Bazel is developed by Google itself right now. Presumably if you missed Google tooling you'd rather use Bazel, no? I'm not suggesting Bazel is perfect: I think e.g. Starlark's insistence on being a separate language does more harm than good. (FWIW I also think the JVM objection is a little silly.) But I am saying preferring the Google tooling would ostensibly mean you like Bazel a lot already :)
Earlier quoted context omitted.
The problem with Make is that it doesn't know what it's building, so it can't do anything smart. For incremental builds to work at all, you have to supply the smarts. Having worked on a number of make-based projects (I am most scarred by buildroot), I can tell you that people make mistakes with build rules. The project then devolves to doing a clean build for every change, turning what could be a few milliseconds of…
I am personally not convinced that any build system can be correct and general, but perhaps that’s my lack of experience speaking. On that 30 minute note though: so, how big does the project need to be in order for Make not to be enough? And at that size, why wouldn’t the project invest the extra week it takes to get the Makefile correct?
In my opinion, this is a bit similar to languages with static vs dynamic typing.
If your current setup works well for you, it makes sense to keep it, though.
Earlier quoted context omitted.
No thanks, I want my binaries to use shared objects so that an entire OS can receive quick security updates. And I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy.
> I want my binaries to use shared objects so that an entire OS can receive quick security updates. Have shared libraries historically improved security much? Debian helpfully "updated" OpenSSL, and thanks to the magic of shared libraries, every program on a Debian system generated weak keys. Personally, I don't think there's enough software on the average filesystem image to justify sharing libraries. Most stuff "in…
I'm going to guess you never checked how many vulnerabilities have been fixed in Linux distributions before a release, or backported to existing releases: hundreds of thousands.
Cherry-picking a single incident (involving a library with a history of vulnerabilities) is hardly meaningful.
> Most stuff "in production" these days is in a container
It's provably not, outside of the SV bubble. The large majority of software in the world is still deployed traditionally.
> So the "quick security updates" doesn't seem to justify the high maintainability cost of shared libraries
A good number of large companies think otherwise. Also, people working in security.
>> I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy. > You've just invented containers.
No, these are OS packages and predate containers by many decades. This is getting silly.
How easy is it to "port" BUILD files between the various open implementations (Bazel, Buck, Pants, Please)? If you have a project someone else wrote with the intention of using it in e.g. Bazel, can you integrate it into your Please build system, or would you need to treat it as an opaque build process (same as if you were shelling out to ./configure && make)? As a concrete example, one frustration at $DAYJOB is that…
On the BUILD file level, Buck is using the Starlark. Pants and Please are close enough that some tooling (e.g. buildifier) can be shared. But that's about it.