On Fri, 08 Aug 2025 13:23:37 +0200 Cayetano Santos <csant...@inventati.org> wrote:
> "fpga" concerns more than fpgas, Are you referring to gtkwave? To me beside gtkwave and openfpgaloader everything is related to HDL. > and should be merged with "electronics" Given that a lot of packages are also in engineering.scm, I think that if we want to improve things (at the cost of backward compatibility) it would be better to rename fpga.scm to hdl.scm instead. This would mean: - openfpgaloader would be moved from fpga.scm in flashing-tools.scm - gtkwave could be moved from fpga.scm to electronics.scm (as there is already sigrok related packages there) or engineering.scm (there are a lot of simulation tools there too, but electronics seems more specific) - abc-yosyshq, json-for-vhdl, prjtrellis, opensta, osvvm, python-cocotb, python-cocotb-bus, python-edalize, python-pydigitalwavetools, python-surf, python-vsg, symbiyosys, could also be moved from electronics.scm to hdl.scm. - minipro could be moved from electronics.scm to flashing-tools.scm The good side of this move would be that with hdl.scm one would be pretty sure of what goes in there and what doesn't. And this would also ensure that we don't have everything in a huge file. For instance any HDL synthetisis or simulation tool should go there, but not tools to program FPGAs (flashing tools) nor more general simulation programs (like gtkwave). I also found some small things that can be moved: - python-esptool could be moved from engineering.scm to bootloaders.scm Beside that I've not looked in details into the rest, as one thing to avoid here would be to have file names that don't convey clear boundaries as of what goes or doesn't go there. A good example is that the content of electronics.scm and engineering.scm overlap a lot, for instance both have simulation tools for digital circuits, PCB capture tools and so on. engineering.scm also has a wide variety of tools, from PCB capture, CAD software, binary reverse engineering tools, tools to work with serial port, etc. So there would be room for improvement here, and personally If we move things, I would be more inclined to move things carefully, like in the hdl.scm move I propose, to make sure that the changes are worth the issues (lack of backward compatibility can make bisect harder) and that basically we don't end re-creating new files with very vague boundaries. And at the end of the day the vague boundaries carry of packaging twice the same thing (it happened to me), and also make contributions easier, so there is also clear benefit. The question is more if it worth the cost of breaking backward compatibility (assuming the boundaries are clear). Denis.
pgplFlwk6HPrE.pgp
Description: OpenPGP digital signature
