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?
Please – A cross-language build system
101–110 of 257 posts
Re: Please – A cross-language build system
#102Re: Please – A cross-language build system
#103First 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…
Re: Please – A cross-language build system
#104I 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.
Re: Please – A cross-language build system
#105Earlier 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?
(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
#106Earlier 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…
Re: Please – A cross-language build system
#107Earlier 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.
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
#108Re: Please – A cross-language build system
#109Have 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.
Re: Please – A cross-language build system
#110I 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.