+
|
+
|
+
+
+
This repository contains references to package recipes (PKGBUILD files) for electronic design automation (EDA) tools/projects to be built as MinGW-w64 targets on MSYS2 (MINGW32 and MINGW64). The main purpose is coordination of contributions for upstreaming all tools/projects to official MSYS2 repositories, and having them updated periodically. See Context for a discussion about other packaging alternatives for EDA tooling.
+Context
+Multiple open source and/or free EDA tools are developed and primarily used on GNU/Linux platforms. Typically, builds are managed with tools such as make or cmake, and GCC or LLVM/Clang are used for compiling. Migrating all those build systems to native Windows toolchains can be painful. Using PKGBUILD files for MINGW32/MINGW64 allows reusing the existing plumbing and, at the same time, produced binaries can be used on Windows natively. MSYS2 is the most used environment for building open source EDA tools already; however, most projects don’t use PKGBUILD recipes but custom scripts. Hence, the work on this project is mainly rewriting custom scripts for adhering to MSYS2 packaging guidelines.
Overall, there are a handful of approaches for providing great prepackaged/prebuilt and easy-to-set-up EDA tooling environments: see hdl/packages.
+Packages/tools
+The complete list of available MSYS2 packages is shown at packages.msys2.org/package. When first upstreamed, packages are shown at packages.msys2.org/new until maintainers of MSYS2 sign them and move them to the official repositories. By the same token, when updates or patches are upstreamed, packages are shown at packages.msys2.org/queue until signed and uploaded. Therefore, users and contributors should expect some delay between updates being accepted in msys2/MINGW-packages and changes being available in official repositories.
+The following tables summarise the state (🟪 upstreamed, 🟩 ready but not upstreamed, 🟧 work in progress, ⬜ to do) of EDA related packages, and provide references to relevant issues/PRs regarding their support on MSYS2.
+| Tool | +State | +PKGBUILD (Packages) | +PRs | +References | +open-tool-forge/fpga-toolchain (static) | +
|---|---|---|---|---|---|
| + | ⬜ |
++ | + | + | ❔ |
+
| + | ⬜ |
++ | + | + | ✔️ |
+
| + | 🟪 |
++ | + | + | ❔ |
+
| + | 🟪 |
+mingw-w64-ghdl ( + i686, + x86_64 +) |
+#5757 + #6688 + #7510 + #7606 + #7685 + #7817 + #7880 + #8180 + #8260 + #8451 + #8621 + #8934 + #9172 + #9468 + #9495 + #9597 + #9679 + #9790 + #9997 + #10198 + #10449 + #10548 + #11397 + #11897 + #12901 + #13819 + #15939 |
++ | ✔️ |
+
| + | 🟪 |
+Built in yosys (see below) |
+- |
++ | ✔️ |
+
| + | 🟪 |
++ | + | + | ❔ |
+
| + | 🟪 |
++ | + | + | ❔ |
+
| + | 🟪 |
++ | + | + | ✔️ |
+
| + | 🟪 |
++ | #7341 + #7401 + #7967 + #8180 + #9172 + #9444 + #9495 + #9597 + #9997 + #10198 + #10505 + #11397 |
++ | ❔ |
+
| + | 🟧 |
+umarcor/MINGW-packages@imhex: mingw-w64-imhex umarcor/MINGW-packages@imhex-1.6.1: mingw-w64-imhex |
++ | + | ❔ |
+
| + | 🟪 |
++ | + | + | ❔ |
+
| + | ⬜ |
++ | + | + | ❔ |
+
| + | 🟪 |
++ | #7542 + #8231 + #8956 + #9172 + #9444 + #9495 + #9597 + #9679 + #9790 + #9997 + #10198 + #10282 + #10449 + #10505 + #11468 |
++ | ✔️ |
+
| + | 🟪 |
++ | + | + | ❔ |
+
| + | 🟪 |
++ | #7509 + #8180 + #8414 + #8466 + #8956 + #9172 + #9597 + #10449 + #10573 + #11435 |
++ | ✔️ |
+
| + | 🟪 |
++ | #8676 + #8972 + #9172 + #9444 + #9485 + #9524 + #9997 + #10198 |
++ | ❔ |
+
| + | 🟪 |
++ | + | + | ❔ |
+
| + | ⬜ |
++ | + | + | ❔ |
+
| + | 🟧 |
++ | + | + | ❔ |
+
| + | ⬜ |
++ | + | + | ✔️ |
+
| + | ⬜ |
++ | + | + | ❔ |
+
| + | 🟧 |
++ | + | + | ❔ |
+
| + | ⬜ |
++ | + | + | ❔ |
+
| + | 🟪 |
++ | #7424 + #7872 + #8180 + #8465 + #8954 + #9111 + #9790 + #10282 + #10587 + #11247 + #11898 + #12900 + #13820 + #14598 + #15350 |
++ | ❔ |
+
| + | ⬜ |
++ | + | + | ❔ |
+
| + | ⬜ |
++ | + | + | ❔ |
+
| + | ⬜ |
++ | + | + | ❔ |
+
| + | ⬜ |
++ | + | + | ❔ |
+
| + | 🟪 |
++ | + | + | ✔️ |
+
| + | 🟪 |
++ | #7534 + #7606 + #7965 + #8180 + #8290 + #8956 + #9172 + #9444 + #9495 + #9597 + #9679 + #9790 + #9997 + #10198 + #10449 |
++ | ✔️ |
+
| + | 🟪 |
++ | + | + | ✔️ |
+
| Board programming | +State | +PKGBUILD (Packages) | +PRs | +References | +open-tool-forge/fpga-toolchain (static) | +
|---|---|---|---|---|---|
| + | 🟪 |
++ | + | + | ✔️ |
+
| + | 🟪 |
++ | + | + | ✔️ |
+
| + | 🟧 |
++ | + | + | ❔ |
+
| + | 🟪 |
++ | + | + | ❔ |
+
| + | 🟪 |
++ | #7351 + #7404 + #7641 + #7971 + #8300 + #8965 + #8995 + #9160 + #9280 + #10224 + #10282 + #10449 + #11213 + #14686 |
++ | ✔️ |
+
| + | 🟪 |
++ | + | + | ❔ |
+
Usage
+++ +++MSYS2 (…) provides a native build environment, based on open source software, and makes you feel right at home when you are already comfortable with Linux.
+
++ +++In MSYS2 there are 2 types of packages:
++++
+- +
+MSYS packages - these run on the emulation layer and are typically POSIX-only programs.
+- +
+MINGW packages - these run natively just like any other Windows program.
+++You should think of these two systems as separate where msys packages should generally only be build dependencies of mingw packages.
+
++ +++There are 3 package repositories, msys2, mingw32, and mingw64. The packages in msys2 are named just like on a Linux distribution, the packages in mingw are prefixed by either
+mingw-w64-i686-for 32-bit packages, ormingw-w64-x86_64-for 64-bit packages.
That is, projects/tools on MSYS2 feel like Unix when it comes to building them (GCC, clang, make, cmake, etc.), but the artifacts are native Windows binaries ("just like any other Windows program"). Typically, users want to install mingw-w64-x86_64- packages, which can be used outside of an MSYS2 environment optionally.
| + + | ++See how to launch MSYS2 shells/terminals or how to use Windows Terminal at msys2.org: Terminals. + | +
| + + | ++msys2.org: Avoiding writing long package names + | +
Installation
+MSYS2 can be downloaded as a tarball or as a self-extracting installer with an optional GUI. Nevertheless, both of them produce the same result because MSYS2’s installations are portable by default; i.e. they don’t create any environment variables or registry entries on the system. For this same reason, it’s possible to have several MSYS2 installations at the same time, without them colliding. Find the latest installers/tarballs at github.com/msys2/msys2-installer/releases and follow the guidelines at msys2.org/#installation.
+MSYS2 borrows the package management plumbing from Arch Linux (see msys2.org: MSYS2 vs Arch Linux). The default package manager is pacman, which is the same codebase as Arch’s but ported/patched to work on MSYS2 (Windows). Guidelines for MSYS2’s pacman are available at msys2.org: Package Management. Nonetheless, guidelines at wiki.archlinux.org/index.php/pacman and wiki.archlinux.org/index.php/pacman/Tips_and_tricks can also be useful.
Individual packages
+All upstreamed EDA packages are available through the default package manager (pacman), as any other regular MSYS2 package. Hence, you can search them with pacman -Ss TOOL_NAME (see msys2.org: Finding a package) and then install them with pacman -S PACKAGE_NAME (see msys2.org: Installing a package). Find further info at msys2.org/docs/package-management.
Package group eda
+Alternatively, there is a package group named eda, which you can install with pacman -S mingw-w64-x86_64-eda (64 bits) or pacman -S mingw-w64-i686-eda (32 bits). The list of tools will be shown, for you to choose installing all of them or some only. See mingw-w64-x86_64-eda and/or mingw-w64-i686-eda.
Contributing
+The official git repository for PKGBUILD recipes targeting MINGW32|MINGW64 (MSYS2) is msys2/MINGW-packages. Due to GitHub’s permission management constraints, it is undesirable to open Pull Request (PRs) across organisations. Therefore, all contributions regarding PKGBUILD recipes are handled in repositories from users'/contributors' namespaces and opened against msys2/MINGW-packages. That allows MSYS2 maintainers to edit PRs in-place. Anyway, hdl/MINGW-packages can be used for discussion and coordination of tightly coupled EDA packages.
+Other than that, branch main contains testing and tracking resources, on top of MSYS2’s infrastructure:
-
+
-
+
On MSYS2’s CI, packages are built with option
+--nocheck. Therefore, only successful builds are check, not runtime dependencies or other possible broken artifacts. In this repo, EDA packages are installed and tested every day.
+ -
+
On MSYS2’s workflow, packages are neither rebuilt nor updated periodically. They are checked and bumped upon users'/contributors' demand. Therefore, it is easy for less used packages to become either outdated or broken. In this repo, EDA packages are built weekly, in order to avoid them rotting.
+
+
| + + | ++We’d like to provide additional features, such as building EDA packages from git heads, as a complement to tagged/fixed builds; or automatically checking when are new releases available. Should be willing to contribute, get in touch! + | +
MSYS2 borrows the package management plumbing from Arch Linux. That is, PKGBUILD recipes and makepkg are used. It’s the same same codebase, but patched to work on MSYS2 (Windows). Therefore, upstream repositories are different. Apart from that, the usage is the same, and PKGBUILD files for MSYS2 are very similar to the equivalent recipes for Arch Linux.
-
+
-
+
+++
-
+
-
+
++ ++
+
- + + +
+ -
+
+
- + + + +
Testing
+Branch main contains subdir test and a Continuous Integration (CI) workflow which is scheduled periodically. There should be a test script and a job for each EDA tool. Smoke-tests from hdl/smoke-tests are used before running heavier tests.
| + + | ++Tagged/fixed versions of the tools are built periodically. It would be desirable to have an scheduled workflow for building the head of each downstream repo too. Do you want to tackle the challenge? Contributions are welcome! + | +
Updating packages
+MSYS2 repositories are compared against matching packages on Arch Linux, and mismatches are shown at packages.msys2.org/outofdate. That’s the easiest way for finding outdated packages. However, many EDA tools are not upstreamed to Arch Linux yet; thus, those are not shown there. It is therefore useful if frequent users of the tools watch the corresponding repostories and communicate updates either through this repository or through msys2/MINGW-packages.
+| + + | ++Since most projects use source control management (SCM) tools, it should be feasible to have an script for checking new releases automatically. Should you be up to the challenge, contributions are welcome! + | +
The process for bumping a package is very simple (when explained, at least):
+-
+
-
+
Fork and checkout the latest
+masterbranch from msys2/MINGW-packages and create a feature branch.
+ -
+
Edit the PKGBUILD recipe of the tool:
+++-
+
-
+
Change the version.
+
+ -
+
Reset
+pkgrel.
+ -
+
If the tool is retrieved as a tarball, update the checksum.
+
+ -
+
Check if any patches exist. Either remove them (if not necessary anymore), update them (if sources changed), or keep them.
+
+
+ -
+
-
+
Commit and push.
+
+ -
+
CI will run and it will build the package.
+
+
In practice, checking and updating the patches might be not so simple. Should modifying them be required, see Testing PKGBUILD recipes downstream below.
+Adding new packages
+All the ⬜ tools/projects in the list are to be packaged yet. Furthermore, there might be other interesting tools which you’d like to upstream, even if not listed above (yet).
+TBC
+On MSYS2 native windows executables (or DLLs) are built, but the paths in the (bash) shell use the UNIX syntax. Hence, typically the makefiles/scripts of the projects need to be tweaked. Sometimes there is luck, and an Arch Linux recipe works almost as is, but chances are that some defines need to be added.
+Testing PKGBUILD recipes downstream
+Should modifying/patching downstream sources be required, the recommended procedure is the following:
+-
+
-
+
Checkout the desired version of the project/tool repository and create a feature branch.
+
+ -
+
Create subdir
+msys2and add the PKGBUILD recipe.++-
+
-
+
Remove non-external
+sourceentries and the corresponding checksums from the recipe.
+ -
+
Modify the paths to use the sources in the parent directory.
+
+
+ -
+
-
+
Copy testing-workflow.yml to
+.github/workflows/(create the subdir if it does not exist).
+ -
+
Modify the last step in the workflow for testing the tool.
+
+ -
+
Commit and push.
+
+ -
+
CI will run in your fork of the downstream repo.
+
+
Build issues and regressions should arise. You can commit your fixes to the feature branch and push again. Since the workflow and the PKGBUILD recipe build the head of the branch, there is no need to generate patches yet.
+TBC
+-
+
-
+
Discuss solutions with maintainers.
+
+ -
+
Propose having the MSYS2 CI added downstream.
+
+ -
+
How to generate patches and apply them to the PKGBUILD recipe to be upstreamed.
+
+