search

YosysHQ / oss-cad-suite-build

Multi-platform nightly builds of open source digital design and verification tools
ISC License
732 stars 67 forks source link

Scope of the project #1

Open umarcor opened 3 years ago

umarcor commented 3 years ago

By looking at the sources of this repo, it seems that the project is to generate artifacts for a wide range of platforms (both OSs and architectures). That's nice! However, I'm lacking some explanation in the README for understanding how does this fit with other similar projects in the ecosystem. I'd like to gather some information for listing it in hdl/packages and forwarding people for which this is the best solution.

Precisely, YosysHQ/fpga-toolchain is based on prior work by Miodrag, who did also contribute to apio. See https://github.com/YosysHQ/fpga-toolchain#credits and https://github.com/FPGAwars/toolchain-ecp5. Moreover, builds in fpga-toolchain are nightly/daily too. The main feature of fpga-toolchain is that tools are built statically.

In this repo:

On the one hand, I'm not sure about the motivation for having a container for Windows cross-compilation and an MSYS2 CI job at the same time. I would expect one or the other to be used.

On the other hand, it seems that most of the tools are still built statically. Hence, is this a drop-in replacement for fpga-toolchain (with a different codebase and build environments)?

Furthermore, are you expecting to provide containers to end users? Or are those only for using a custom and portable build environment?

With regard to MSYS2, similarly to fpga-toolchain, you seem to have a significant number of tweaks for trying to use the same plumbing as for other platforms. However, IMHO, building a distribution of tools for/through MSYS2 is better done using the built-in package manager (pacman), PKGBUILD recipes and makepkg-mingw. In fact, the following works already:

# Extract https://github.com/msys2/msys2-installer/releases/download/2021-02-28/msys2-base-x86_64-20210228.tar.xz and open a MINGW64 shell
# NOTE: https://github.com/msys2/setup-msys2/blob/master/main.js#L12

# pacman -Syu
...

# pacman -S mingw-w64-x86_64-eda
:: There are 21 members in group mingw-w64-x86_64-eda:
:: Repository mingw64
   1) mingw-w64-x86_64-dfu-util
   2) mingw-w64-x86_64-ecpprog
   3) mingw-w64-x86_64-fritzing
   4) mingw-w64-x86_64-ghdl-llvm
   5) mingw-w64-x86_64-gtkwave
   6) mingw-w64-x86_64-icesprog
   7) mingw-w64-x86_64-icestorm
   8) mingw-w64-x86_64-iverilog
   9) mingw-w64-x86_64-kicad
   10) mingw-w64-x86_64-kicad-footprints
   11) mingw-w64-x86_64-kicad-meta
   12) mingw-w64-x86_64-kicad-packages3D
   13) mingw-w64-x86_64-kicad-symbols
   14) mingw-w64-x86_64-kicad-templates
   15) mingw-w64-x86_64-nextpnr
   16) mingw-w64-x86_64-ngspice
   17) mingw-w64-x86_64-openFPGALoader
   18) mingw-w64-x86_64-prjtrellis
   19) mingw-w64-x86_64-serial-studio
   20) mingw-w64-x86_64-verilator
   21) mingw-w64-x86_64-yosys

Enter a selection (default=all):

Find links to each of the recipes in https://hdl.github.io/MINGW-packages/#_packagestools and https://packages.msys2.org/group/mingw-w64-x86_64-eda. Recipes are located in https://github.com/msys2/MINGW-packages/.

The official recipes use fixed commits/tags. There are two workflows in hdl/MINGW-packages for keeping track of breaking changes and/or outdated packages:

On the one hand, you might use those workflows as a reference for working around the timeout issues you have in CI. On the other hand, you might want to customise those recipes for building main/master/head of the projects, instead of fixed versions. That would make your build procedure on/for Windows different from others. Yet, supporting cross-compilation for arm, arm64, riscv64 and amd64 is a huge task already. Hence, reducing the complexity of the Windows infrastructure would allow you to focus on the foreign linux builds.

Personally, I like contributing workflows for building main/master/head to the projects, instead of doing it in orgs MSYS2 or HDL. See: iverilog, verilator, gtkwave, GHDL, Serial-Studio, etc. There is a reference workflow in https://hdl.github.io/MINGW-packages/#_testing_pkgbuild_recipes_downstream, together with some brief guidelines.

Note that MSYS2 packages are tarballs. Therefore, YosysHQ could potentially have a mirror/repository with custom builds/versions, should you want to. Alternatively, you can publish assets in a 'nightly' release:

A similar strategy is used in MSYS2 for staging packages: https://github.com/msys2/msys2-autobuild/releases. See also https://packages.msys2.org/queue.

Nevertheless, MSYS2 maintainers are really fast. For instance: https://github.com/msys2/MINGW-packages/pull/8180. Therefore, I don't think it's worth maintaining an independent set of nightly packages, unless you want to have very specific build options and/or combine tools with non-free software. Typically, any update will be available for everyone in 1-3 days after opening a PR.

No matter which strategy you follow, let me know if you need any hint about MSYS2/MINGW packages (hdl/MINGW-packages), QEMU and Docker (dbhi/qus) and/or MSYS2 on GitHub Actions (msys2/setup-msys2). I'm not an expert in either of them, but I do have experience with all and I'd be glad to help you make the best of your time.

Cheers

mmicko commented 3 years ago

Hi Unai,

Thank you for your feedback and useful tips. As you have noticed this is not something that is quite finished, and I do work on solving the rest of the issues and cleaning up scripts to a maintainable level, and that is the major reason why proper README content is missing. We published it a bit earlier then foreseen to be able to test GitHub actions and check if we can use it.

Anyway this project started as my effort of making a build system for our commercial package, but in mind of greater OS support. Since it was modular I have started from beginning to make it ready for public build as well, since we have a lot of people interested in using open source stack but have problems setting all solvers and can't keep up with updating all tools they need to update. So this was made as a self-contained system to build binary non-static releases but still able to execute on various distributions without a change. Containers are there just for building projects and all things you need to run software is packaged (check default.sh for how it is done, note that for Windows I rely on setting PATH for now for DLL loading, but looking into better solution).

Note that static build is easier to make portable, but this is not possible for GUI tools, those that integrate python or others that rely on dynamic loading of plugins.

Since there are a lot of possible supported platforms, but not sure we are going to be able to make releases for all (at least not from start) it is easy to set up the build environment and do the checks. Also this allows adding new packages for any external contributor much easier. First I have added Windows support for msys2 since that seems natural, but makes things complicated for CI and testing (if you have linux based machines only) so I made docker based one, but still have some limitations there (missing ADA compiler, so no GHDL build possible for now).

We are still not announcing this project until there are working builds available to download, but it is good to have more people testing and giving their suggestions. Will see to improve preview of build status of packages per platform, so it is known what users can expect to have in the final build ( there are certain solvers that are linux only, or just can work on windows for example). In time I also plan to upstream some of the changes to projects used to make scripts easier to maintain but also those projects more compatible with certain OS-es.

For now I would concentrate on FPGA based EDA software that is already in and make that building nice before attempting to add something else.

On Wed, Mar 24, 2021 at 3:32 AM Unai Martinez-Corral < @.***> wrote:

By looking at the sources of this repo, it seems that the project is to generate artifacts for a wide range of platforms (both OSs and architectures). That's nice! However, I'm lacking some explanation in the README for understanding how does this fit with other similar projects in the ecosystem. I'd like to gather some information for listing it in hdl/packages https://github.com/hdl/packages and forwarding people for which this is the best solution.

Precisely, YosysHQ/fpga-toolchain https://github.com/YosysHQ/fpga-toolchain is based on prior work by Miodrag, who did also contribute to apio. See https://github.com/YosysHQ/fpga-toolchain#credits and https://github.com/FPGAwars/toolchain-ecp5. Moreover, builds in fpga-toolchain are nightly/daily too. The main feature of fpga-toolchain is that tools are built statically.

In this repo:

  • Python is used for the plumbing, instead of bash.
  • The tools are cross-compiled on containers, instead of using the CI environments (typically Ubuntu).
  • At the same time, there is a Windows job in CI, which builds tools on MSYS2 "natively".

On the one hand, I'm not sure about the motivation for having a container for Windows cross-compilation and an MSYS2 CI job at the same time. I would expect one or the other to be used.

On the other hand, it seems that most of the tools are still built statically. Hence, is this a drop-in replacement for fpga-toolchain (with a different codebase and build environments)?

Furthermore, are you expecting to provide containers to end users? Or are those only for using a custom and portable build environment?

With regard to MSYS2, similarly to fpga-toolchain, you seem to have a significant number of tweaks for trying to use the same plumbing as for other platforms. However, IMHO, building a distribution of tools for/through MSYS2 is better done using the built-in package manager (pacman), PKGBUILD recipes and makepkg-mingw. In fact, the following works already:

Extract https://github.com/msys2/msys2-installer/releases/download/2021-02-28/msys2-base-x86_64-20210228.tar.xz and open a MINGW64 shell# NOTE: https://github.com/msys2/setup-msys2/blob/master/main.js#L12

pacman -Syu

...

pacman -S mingw-w64-x86_64-eda

:: There are 21 members in group mingw-w64-x86_64-eda: :: Repository mingw64 1) mingw-w64-x86_64-dfu-util 2) mingw-w64-x86_64-ecpprog 3) mingw-w64-x86_64-fritzing 4) mingw-w64-x86_64-ghdl-llvm 5) mingw-w64-x86_64-gtkwave 6) mingw-w64-x86_64-icesprog 7) mingw-w64-x86_64-icestorm 8) mingw-w64-x86_64-iverilog 9) mingw-w64-x86_64-kicad 10) mingw-w64-x86_64-kicad-footprints 11) mingw-w64-x86_64-kicad-meta 12) mingw-w64-x86_64-kicad-packages3D 13) mingw-w64-x86_64-kicad-symbols 14) mingw-w64-x86_64-kicad-templates 15) mingw-w64-x86_64-nextpnr 16) mingw-w64-x86_64-ngspice 17) mingw-w64-x86_64-openFPGALoader 18) mingw-w64-x86_64-prjtrellis 19) mingw-w64-x86_64-serial-studio 20) mingw-w64-x86_64-verilator 21) mingw-w64-x86_64-yosys

Enter a selection (default=all):

Find links to each of the recipes in https://hdl.github.io/MINGW-packages/#_packagestools and https://packages.msys2.org/group/mingw-w64-x86_64-eda. Recipes are located in https://github.com/msys2/MINGW-packages/.

The official recipes use fixed commits/tags. There are two workflows in hdl/MINGW-packages for keeping track of breaking changes and/or outdated packages:

- https://github.com/hdl/MINGW-packages/blob/main/.github/workflows/build.yml builds the recipes. Since MSYS2 is a rolling environment, builds might break and/or the tools might need to be rebuilt.

https://github.com/hdl/MINGW-packages/blob/main/.github/workflows/test.yml tests the latest available packages with main/master/head test suites. This allows knowing when packages are outdated because some new feature was added.

On the one hand, you might use those workflows as a reference for working around the timeout issues you have in CI. On the other hand, you might want to customise those recipes for building main/master/head of the projects, instead of fixed versions. That would make your build procedure on/for Windows different from others. Yet, supporting cross-compilation for arm, arm64, riscv64 and amd64 is a huge task already. Hence, reducing the complexity of the Windows infrastructure would allow you to focus on the foreign linux builds.

Personally, I like contributing workflows for building main/master/head to the projects, instead of doing it in orgs MSYS2 or HDL. See: iverilog https://github.com/steveicarus/iverilog/blob/master/.github/workflows/test.yml?rgh-link-date=2021-03-23T04%3A42%3A39Z, verilator https://github.com/verilator/verilator/pull/2681, gtkwave https://github.com/gtkwave/gtkwave/blob/master/.github/workflows/build.yml?rgh-link-date=2021-03-23T04%3A42%3A39Z, GHDL https://github.com/ghdl, Serial-Studio https://github.com/Serial-Studio/Serial-Studio/tree/master/msys2, etc. There is a reference workflow in https://hdl.github.io/MINGW-packages/#_testing_pkgbuild_recipes_downstream, together with some brief guidelines.

Note that MSYS2 packages are tarballs. Therefore, YosysHQ could potentially have a mirror/repository with custom builds/versions, should you want to. Alternatively, you can publish assets in a 'nightly' release:

A similar strategy is used in MSYS2 for staging packages: https://github.com/msys2/msys2-autobuild/releases. See also https://packages.msys2.org/queue.

Nevertheless, MSYS2 maintainers are really fast. For instance: msys2/MINGW-packages#8180 https://github.com/msys2/MINGW-packages/pull/8180. Therefore, I don't think it's worth maintaining an independent set of nightly packages, unless you want to have very specific build options and/or combine tools with non-free software. Typically, any update will be available for everyone in 1-3 days after opening a PR.

No matter which strategy you follow, let me know if you need any hint about MSYS2/MINGW packages (hdl/MINGW-packages https://github.com/hdl/MINGW-packages), QEMU and Docker (dbhi/qus https://github.com/dbhi/qus) and/or MSYS2 on GitHub Actions ( msys2/setup-msys2 https://github.com/msys2/setup-msys2). I'm not an expert in either of them, but I do have experience with all and I'd be glad to help you make the best of your time.

Cheers

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/YosysHQ/fpga-nightly/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3UUSDXJ3STE4FXGHA7IG3TFFFLVANCNFSM4ZWLLVEA .

umarcor commented 3 years ago

Anyway this project started as my effort of making a build system for our commercial package, but in mind of greater OS support.

Is "your commercial package" Tabby CAD? Is there any non-open tool in the bundle apart from Verific's parser/frontend? I only found lists of the open source tools included.

we have a lot of people interested in using open source stack but have problems setting all solvers and can't keep up with updating all tools they need to update.

I would very strongly suggest you to distribute one container, at least, even if temporarily. In general, I don't like large monolithic containers, because of technical and conceptual reasons. However, that is the fastest solution for making any custom set of tools available to any user. That is because you need to care about a single Linux environment (pick the base image that you wish). The same image can then be used in CI, on Linux, Windows or MacOS. Once you have that first problem solved, you can focus on more granular build and distribution solutions. In a sense, I'm proposing you to focus on a subset of what you already have, since all the tools are already built/tested on some Debian/Ubuntu, you avoid all that custom copying of shared libs.

For formal verification, @tmeissner contributed multiple solvers to https://hdl.github.io/containers/#_tools_and_images. Precisely, image formal contains boolector, cvc4, superprove, yices2 and z3, apart from GHDL, Yosys and SymbiYosys. You can use it as a base and add the Verific frontend as a plugin on top of it. Also, whichever additional solvers you provide in Tabby CAD. Alternatively, you can clone/fork the repo and customise the dockerfiles to your needs; or you can have a look at it and use it for inspiration. If you want to share some effort, I'd be glad to discuss how can I/we reshape hdl/containers for making it more appealing to your needs.

NOTE: unlike MINGW-packages, in the containers ghdl-yosys-plugin is a library. Therefore, there should be no conflict for your clients to have both GHDL and Verific in the same environment.

for Windows I rely on setting PATH for now for DLL loading, but looking into better solution

I don't know whether any better solution exists. The canonical approach on MSYS2 is to install all DLLs to /bin, precisely for having all of them automatically available in the PATH without dealing with additional locations.

Note that static build is easier to make portable, but this is not possible for GUI tools, those that integrate python or others that rely on dynamic loading of plugins.

Indeed... Yet, my very personal opinion is that maintaining a custom build procedure needs to pay off due to some specific feature or use case which is not supported by upstream solutions. In the case of fpga-toolchain or apio, that added value was/is the portability and ease of installation, at the cost of certain features. At the same time, when those projects were created, many EDA tools were not upstreamed to official repositories yet.

Conversely, nowadays most of the tools are already packaged as DEB, RPM and/or PKGBUILD recipes. Therefore, I think that salsa, copr, aur, homebrew, nixos, etc. are a better fit for maintaining a complex multi-arch set of tools. In fact, this is not just a comment. I expect to replace the build procedures in hdl/containers with proper DEB and/or RPM recipes. That's because the added value of containers is the containerization itself. The recipes can and should be shared with "native" users.

IMVHO, your strong point is that you are the developers or relevant contributors of most of the tools in Tabby CAD. Therefore, you have very first hand information about upcoming challenges and potentially conflicting changes. You can foresee the work that packagers will need to do in the following update. You are also in a unique position for adding the features that your clients need, and having them published ASAP. Hence, I would like to very politely ask you to reconsider whether supporting recipes, CI and distribution of 12+ tools on 4+ archs is something that 1-2 people can develop and maintain on their own. It is my very honest believe that you would be more valuable for the open source EDA community if you balanced towards focusing on communication skills; on closing any existing gap between the development of that tools and the packagers in the major distributions. I'm pretty sure you'd get good help if you asked the community "we want help for having nightly DEBs and RPMs of all YosysHQ projects". Then, you could maintain this repository (the Python part) as a wrapper around those DEB, RPM, PKGBUILD and brew recipes. You would focus on your expertise: the integration of the tools in a bundle (not actually building and cross-compiling). At the same time, contributors would not need to learn your custom plumbing, but they'd contribute with their specific knowledge.

Please, note that I'm suggesting this because I know the effort it takes to maintain all these tools on two different environments for amd64 only (and very few multiarch). That is less than half of the work you explained in your scope! In those cases, allowing contributors not to understand the plumbing and allowing myself not to know the usage details of each tool did help all of us move forward. Of course, you might have additional constraints, demands and requirements which I'm not aware of. Hence, please, accept my apologies, should you consider it intrusive.

I have added Windows support for msys2 since that seems natural, but makes things complicated for CI and testing (if you have linux based machines only) so I made docker based one, but still have some limitations there (missing ADA compiler, so no GHDL build possible for now).

Honestly, I'm not sure that will work. Naturally, I suggest you to confirm with some expert (https://gitter.im/msys2/msys2), but my understanding is that MSYS2 cannot be used on Linux. Some users have tried using Wine, but I don't think it works. This is because the MSYS2 project itself would greatly benefit from building all their packages on Linux machines, but they don't/can't. On Linux you get mingw, not MSYS2. Both projects are similar, but not the same since long time ago. You might still be able to build all the tools using mingw/linux, but I would be careful about naming them MSYS2 or mixing them with actual MSYS2 packages.

Will see to improve preview of build status of packages per platform, so it is known what users can expect to have in the final build ( there are certain solvers that are linux only, or just can work on windows for example).

When the different packaging solutions are slightly more mature (in a few months), I'd like to make a table similar to https://hdl.github.io/MINGW-packages/#_packagestools in hdl/packages, showing the tools and versions available in each packaging solution. That will hopefully allow users to pick the one that fits their needs: FPGA/EDA, Verilog/VHDL/SV, sim/synth/formal, CI/embedded/workstation, etc. For a reference, in MSYS2 they compare themselves to Arch and Cygwin: https://packages.msys2.org/outofdate.

In time I also plan to upstream some of the changes to projects used to make scripts easier to maintain but also those projects more compatible with certain OS-es.

That is really nice to hear. In fact, most (if not all) YosysHQ projects do support MSYS2 already, which really helps maintenance of packages. Must be grateful to the people that did it.

mmicko commented 3 years ago

Sorry for a bit of a late answer. First, thank you for your input and suggestions, sorry if I do not address all your questions, but had a lot of obligations today.

Right TabbyCAD is our product, and regarding software used it is mostly Verific integration that differentiate it from the open source version.

Regarding DEB, RPM, brew, ... it is something I have already played with, the issue is that there would be even more combinations (due to the number of distribution versions you need to support to make sense) and at the end we still need to deliver something to each customer as binary blob. Also note that a number of distributions have their own packages for some of the software we use and we will have conflicts with those (possible to override in most cases, but still an additional burden). In this case having one binary distribution for one architecture makes less effort of maintaining it then writing 5 different recipes and building it for various distribution versions. For sure there are pros and cons for each approach, and it is hard to say something is better until it is late :)

On Wed, Mar 24, 2021 at 1:10 PM Unai Martinez-Corral < @.***> wrote:

Anyway this project started as my effort of making a build system for our commercial package, but in mind of greater OS support.

Is "your commercial package" Tabby CAD https://www.yosyshq.com/tabby-cad-datasheet? Is there any non-open tool in the bundle apart from Verific's parser/frontend? I only found lists of the open source tools included.

we have a lot of people interested in using open source stack but have problems setting all solvers and can't keep up with updating all tools they need to update.

I would very strongly suggest you to distribute one container, at least, even if temporarily. In general, I don't like large monolithic containers, because of technical and conceptual reasons. However, that is the fastest solution for making any custom set of tools available to any user. That is because you need to care about a single Linux environment (pick the base image that you wish). The same image can then be used in CI, on Linux, Windows or MacOS. Once you have that first problem solved, you can focus on more granular build and distribution solutions. In a sense, I'm proposing you to focus on a subset of what you already have, since all the tools are already built/tested on some Debian/Ubuntu, you avoid all that custom copying of shared libs.

For formal verification, @tmeissner https://github.com/tmeissner contributed multiple solvers to https://hdl.github.io/containers/#_tools_and_images. Precisely, image formal contains boolector, cvc4, superprove, yices2 and z3, apart from GHDL, Yosys and SymbiYosys. You can use it as a base and add the Verific frontend as a plugin on top of it. Also, whichever additional solvers you provide in Tabby CAD. Alternatively, you can clone/fork the repo and customise the dockerfiles to your needs; or you can have a look at it and use it for inspiration. If you want to share some effort, I'd be glad to discuss how can I/we reshape hdl/containers for making it more appealing to your needs.

NOTE: unlike MINGW-packages, in the containers ghdl-yosys-plugin is a library. Therefore, there should be no conflict for your clients to have both GHDL and Verific in the same environment.

for Windows I rely on setting PATH for now for DLL loading, but looking into better solution

I don't know whether any better solution exists. The canonical approach on MSYS2 is to install all DLLs to /bin, precisely for having all of them automatically available in the PATH without dealing with additional locations.

Note that static build is easier to make portable, but this is not possible for GUI tools, those that integrate python or others that rely on dynamic loading of plugins.

Indeed... Yet, my very personal opinion is that maintaining a custom build procedure needs to pay off due to some specific feature or use case which is not supported by upstream solutions. In the case of fpga-toolchain or apio, that added value was/is the portability and ease of installation, at the cost of certain features. At the same time, when those projects were created, many EDA tools were not upstreamed to official repositories yet.

Conversely, nowadays most of the tools are already packaged as DEB, RPM and/or PKGBUILD recipes. Therefore, I think that salsa, copr, aur, homebrew, nixos, etc. are a better fit for maintaining a complex multi-arch set of tools. In fact, this is not just a comment. I expect to replace the build procedures in hdl/containers with proper DEB and/or RPM recipes. That's because the added value of containers is the containerization itself. The recipes can and should be shared with "native" users.

IMVHO, your strong point is that you are the developers or relevant contributors of most of the tools in Tabby CAD. Therefore, you have very first hand information about upcoming challenges and potentially conflicting changes. You can foresee the work that packagers will need to do in the following update. You are also in a unique position for adding the features that your clients need, and having them published ASAP. Hence, I would like to very politely ask you to reconsider whether supporting recipes, CI and distribution of 12+ tools on 4+ archs is something that 1-2 people can develop and maintain on their own. It is my very honest believe that you would be more valuable for the open source EDA community if you balanced towards focusing on communication skills; on closing any existing gap between the development of that tools and the packagers in the major distributions. I'm pretty sure you'd get good help if you asked the community "we want help for having nightly DEBs and RPMs of all YosysHQ projects". Then, you could maintain this repository (the Python part) as a wrapper around those DEB, RPM, PKGBUILD and brew recipes. You would focus on your expertise: the integration of the tools in a bundle (not actually building and cross-compiling). At the same time, contributors would not need to learn your custom plumbing, but they'd contribute with their specific knowledge.

Please, note that I'm suggesting this because I know the effort it takes to maintain all these tools on two different environments for amd64 only (and very few multiarch). That is less than half of the work you explained in your scope! In those cases, allowing contributors not to understand the plumbing and allowing myself not to know the usage details of each tool did help all of us move forward. Of course, you might have additional constraints, demands and requirements which I'm not aware of. Hence, please, accept my apologies, should you consider it intrusive.

I have added Windows support for msys2 since that seems natural, but makes things complicated for CI and testing (if you have linux based machines only) so I made docker based one, but still have some limitations there (missing ADA compiler, so no GHDL build possible for now).

Honestly, I'm not sure that will work. Naturally, I suggest you to confirm with some expert (https://gitter.im/msys2/msys2), but my understanding is that MSYS2 cannot be used on Linux. Some users have tried using Wine, but I don't think it works. This is because the MSYS2 project itself would greatly benefit from building all their packages on Linux machines, but they don't/can't. On Linux you get mingw, not MSYS2. Both projects are similar, but not the same since long time ago. You might still be able to build all the tools using mingw/linux, but I would be careful about naming them MSYS2 or mixing them with actual MSYS2 packages.

Will see to improve preview of build status of packages per platform, so it is known what users can expect to have in the final build ( there are certain solvers that are linux only, or just can work on windows for example).

When the different packaging solutions are slightly more mature (in a few months), I'd like to make a table similar to https://hdl.github.io/MINGW-packages/#_packagestools in hdl/packages, showing the tools and versions available in each packaging solution. That will hopefully allow users to pick the one that fits their needs: FPGA/EDA, Verilog/VHDL/SV, sim/synth/formal, CI/embedded/workstation, etc. For a reference, in MSYS2 they compare themselves to Arch and Cygwin: https://packages.msys2.org/outofdate.

In time I also plan to upstream some of the changes to projects used to make scripts easier to maintain but also those projects more compatible with certain OS-es.

That is really nice to hear. In fact, most (if not all) YosysHQ projects do support MSYS2 already, which really helps maintenance of packages. Must be grateful to the people that did it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/YosysHQ/fpga-nightly/issues/1#issuecomment-805770015, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3UUSEL2LU46PMVI2R34G3TFHJDTANCNFSM4ZWLLVEA .