Live data from Hacker News

Please – A cross-language build system

please.build

101–110 of 257 posts

Re: Please – A cross-language build system

#101

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?

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 industry. For these reasons, there isn't much of an open source community making things like Please and Bazel specific to FPGAs. You can set it up yourself, but a packaged product that just works out of the box doesn't exist to my knowledge.

Re: Please – A cross-language build system

#102
post #4
post #2

Title can possibly be modified to mention that this is a tool to build code.

> Please (please.build) 'build' kind of indicates that

From the URL, I thought it was going to be a joke page about developers praying "come on, please build!" at complex build systems.

Re: Please – A cross-language build system

#103
post #95

First thing every software engineer does after leaving Google is rewrite Blaze. Just like every site reliability engineer rewrites borgmon. What I chose to do myself was make Blaze happen using a Makefile config. There's a blog post somewhere where Google talks about why they switched from GNU Make to Blaze c. 2006. if I remember correctly it basically boiled down to not having strict dependency checking. So I though…

Every ex-Google SRE I know is glad they don’t have to deal with Borgmon anymore. I don't think it’s popular these days.

Re: Please – A cross-language build system

#104

I came across the Pants build system [1] the other day, which looks like it shares some similarities. Though currently very specific to Python. The value proposition is also a bit more clearly defined there [2] [1]: https://www.pantsbuild.org/docs/welcome-to-pants [2]: https://www.pantsbuild.org/docs/how-does-pants-work

Hey, Please maintainer here! One of the big differences to the other Blaze like build systems is Please actually doesn't treat any of the built in languages any differently to other languages. They are implemented entirely in the build language which is totally open to you as a consumer of Please. Another big difference is Please is written in Go so there's no dependency on VMs or runtimes.

Bazel is moving in that direction too—the C/C++ rules are built-in, but they’re slowly being extracted into Starlark.

Re: Please – A cross-language build system

#105

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’…

Agree with the OP. I went through both the Python and Go quickstarts. They were easy to follow, but I’m also not seeing the value proposition. The build system has different DSLs for different languages so I’m not seeing the advantage of switching from I.e. go install ./... for Go and setuptools for Python? No offense, but you didn’t answer the question: what’s it good for?

In that case, you can stitch both Python and Go builds together in the same interface, and then tie them into further actions (e.g. Docker builds, Kubernetes), again using the same interface. Neither setuptools nor go build are particularly helpful to that goal.

(I'm one of the original developers, but these days do less maintaining of it than tatskaari does)

Re: Please – A cross-language build system

#106
post #89

Earlier quoted context omitted.

Make build configurations can be difficult to understand for newcomers in the industry. If the goal is to obscure the code, by all means continue using the older tools. If the goal is continued maintenance, then encouraging new engineers to explore and read the codebase with tools they can comprehend is critical. disclaimer: have not used these particular tools, but the domain is nice and polite

I have use all of these tools and your take isn't accurate at all. Make doesn't obfuscate anything more than Plz or CMake or whatever. Here are some real reasons why Make isn't the end-all: - Make doesn't allow platform selection in a nice way. - Make doesn't work on Windows natively (no, NMake doesn't count). - Recursive make doesn't work well at all. - Make doesn't track byproducts or deleted artifacts. - Make does…

[deleted]

Re: Please – A cross-language build system

#107
post #84

Earlier quoted context omitted.

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.

Marketing can be hard not because you don't have something worth marketing, but because marketing is a skill-set largely orthogonal to software development.

That's only true if you define software development in a pretty particular way.

For me, writing code is a way of solving problems for people. That involves listening to them to see how I can help. Then collaborating with them to iteratively make something that fits their needs. Which includes helping them adopt it and get productive with it. To me, all of that is part of software development.

And that's most of the "marketing" that's needed for a free, open-source tool. When that's lacking, I have to wonder to what extent the tool was actually made to solve somebody's problems. As opposed to being created because the developer was excited to build a thing as a technical exercise. Either path is fine, of course, but it's a mistake to confuse the two.

Re: Please – A cross-language build system

#108

Earlier quoted context omitted.

Exactly what I was about to say. Bazel is a monstrosity in terms of how much shite it pulls in to get started.

Is it a monstrosity? You need the JVM but the JVM doesn’t seem like a monster to me.

The JRE is 655.8M on my system.

Re: Please – A cross-language build system

#109
post #46

Have used it in a go mono-repo. It’s own convention on packages and bad integration with IDE makes it a hard sell for me. I mean I just paid for Goland IDE why would I waste my time integrating with something that might or might not work for others. It’s a very hard sell.

Go tools in general have poor integration with build systems other than "go build". One trick I find useful is to use Go modules (and therefore goimports, not goreturns) and structure your build so that it looks like a standard Go module build, even though it's really being built by some other system. In other words, it's a mix of making the build system conform to Go norms and making your IDE adapt to the remaining differences.

Re: Please – A cross-language build system

#110
post #64

I can imagine a project that successfully replicates the entire google developer environment (distributed build system w/ caching, monorepo with presubmit checks, code review, testing, etc) would be successful since ex-googlers would be likely to advocate for it inside their own organizations and most orgs don't have the engineering time to build all this themselves. Without this tooling large organizations tend to s…

A surprisingly hard sell even if your organization has a supermajority of ex-Googlers. There's a really strong meme out there that if you are smaller than Google, which is almost universally true, then you shouldn't adopt their practices even when they are zero-cost and obviously superior.

For me the "obvious" part of "obviously superior" is worth interrogating. Googlers have a very particular way of thinking of things. Which works well enough for Google, I guess. But there are a lot of ways to to good work, and not all of them are compatible.
Post reply on HN