Hacker News Reader

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.

I work in a similar field and this is accurate for us too, except our tools do at least have some integration with Make (you can generate makefiles from the proprietary project files, although it's not useful to us and we don't use it). Like most (I assume), we've built our own build language/system on top of Make. It works but only in a few well-defined ways that modern software shops would probably baulk at. We don't support parallel builds, no caching, only coarse grained incremental builds (at a subproject/library level) and who knows what else that others benefit from.

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.

Reply on news.ycombinator.com